> On Oct 26, 2017, at 8:43 AM, Karl Wagner via swift-evolution > <[email protected]> wrote: > > 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).
I respectfully disagree that it’s a different “level". Architecture is an axis of configuration. OS is an axis of configuration. Target (device vs simulator/emulator) is just another axis of configuration. Dave > > 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 > <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] <mailto:[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] <mailto:[email protected]> >> 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
