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 > <[email protected]> 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 > <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
