-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Fixed NSString/Swift.String Bridging in Locale #1474
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
pvieito
commented
Mar 13, 2018
- Fixed NSString/Swift.String Bridging in Locale
- Added support for Preferred Languages in Linux
- Added tests for Locale static properties and methods
- Also added support for Preferred Languages in Linux
@swift-ci please test |
let euroCurrencyCode = "EUR" | ||
let spainRegionCode = "ES" | ||
let galicianLanguageCode = "gl" | ||
let galicianLocaleIdentifier = Locale.identifier(fromComponents: [NSLocale.Key.languageCode.rawValue: galicianLanguageCode, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the hoop jump through languageCode.rawValue
here? The argument type is [String:String]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any suggestions? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the types are all consistent with Darwin :( so, not an issue that concerns this patch specifically.
Foundation/NSLocale.swift
Outdated
@@ -109,39 +109,39 @@ extension NSLocale { | |||
open class var isoLanguageCodes: [String] { | |||
var identifiers = Array<String>() | |||
for obj in CFLocaleCopyISOLanguageCodes()._nsObject { | |||
identifiers.append((obj as! NSString)._swiftObject) | |||
identifiers.append(obj as! String) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't the result type here CFStringRef
, which is not directly bridgeable to Swift.String
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, they are Swift.String
. If you try to get any of that properties in the actual Swift Foundation implementation they will throw with the following execution:
Could not cast value of type 'Swift.String' (0x7ffff3e61970) to 'Foundation.NSString' (0x7ffff75a9190).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To prevent this kin of confusion, can we just replace the whole thing with:
_SwiftValue.fetch(CFLocaleCopyISOLanguageCodes()) as? [String] ?? []
That's the least confusing primitive for bridging on Linux.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! I'll commit the changes.
@swift-ci please test |
@swift-ci please test |
Could anyone start the CI test, please? |
@swift-ci please test |
1 similar comment
@swift-ci please test |
Any idea why is the CI test not being executed? 🤔 |
@swift-ci please test |
Great! 👍 |
@swift-ci please test and merge |