[swift-evolution] [draft] Target environment platform condition
razielim at gmail.com
Thu Oct 26 09:43:20 CDT 2017
it’s not like I don’t understand when you’d want some different behaviour in a program to account for the simulator’s environment. I just wonder if it’s worth being a built-in part of the language. To me, it feels like something better suited to an ad-hoc build option or global constant.
OS, CPU architecture and endianness are of a different ‘level', IMO. They are typically only useful for very low-level operations (especially once we have #canImport - I expect that to replace most uses of #os with a better, higher-level abstraction).
Really, I think the current TARGET_OS_SIMULATOR compile-time variable is the best approach. Perhaps it could be renamed or aliased to sound nicer from cross-platform code, but I’m not sure it really deserves to be part of the language.
As for the iOS Keychain API - a quick search indicates that they are supposed to work in the simulator since Xcode 7 (see, for example, https://github.com/AzureAD/azure-activedirectory-library-for-objc/pull/673)
> On 26. Oct 2017, at 15:36, BJ Homer via swift-evolution <swift-evolution at swift.org> wrote:
> Example: the iOS Keychain APIs do not support access groups on the simulator, so if you try to make a keychain query that targets an access group, you get no results. This means that in order for my app to operate correctly on simulator, I need to pass different parameters on simulator and device. This is an unfortunate distinction that ideally should not exist in a simulator, but unfortunately such cases do exist.
> (This was at least true in iOS 9, and I haven’t seen any indication that it has changed.)
> On Oct 26, 2017, at 5:43 AM, Karl Wagner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> I’m currently -1 on this, because I don’t think simulator/device is a worthwhile-enough distinction for a built-in condition.
>> - Are you maybe looking for a Debug/Release condition? Because we already have that, through compile-time variables (the “-D” option).
>> - Does your platform’s simulator/emulator expose any additional API? Great! Take a look at #canImport…
>> - Why else would you need to distinguish simulator/device, and why are OS and architecture not sufficient for that case?
>>> On 25. Oct 2017, at 05:05, Graydon Hoare via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> I'd like to propose a variant of a very minor, additive proposal Erica Sadun posted last year, that cleans up a slightly messy idiomatic use of conditional compilation in libraries. The effects should be quite limited; I'd call it a "standard library" addition except that the repertoire of compiler-control statements isn't strictly part of the stdlib.
>>> Proposal is here: https://gist.github.com/graydon/809af2c726cb1a27af64435e47ef4e5d <https://gist.github.com/graydon/809af2c726cb1a27af64435e47ef4e5d>
>>> Implementation (minus fixits) is here: https://github.com/graydon/swift/commit/16493703ea297a1992ccd0fc4d2bcac7d078c982 <https://github.com/graydon/swift/commit/16493703ea297a1992ccd0fc4d2bcac7d078c982>
>>> Feedback appreciated,
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution