[swift-evolution] [draft] Target environment platform condition

[Karl Wagner]

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)

- Karl

> 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.)
> 
> -BJ
> 
> 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?
>> 
>> Karl
>> 
>>> On 25. Oct 2017, at 05:05, Graydon Hoare via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Hi,
>>> 
>>> 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,
>>> 
>>> -Graydon
>>> 
>>> _______________________________________________
>>> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171026/d0c653be/attachment.html>