> On 26. Oct 2017, at 17:13, Dave DeLong via swift-evolution > <[email protected]> wrote: > > >> On Oct 26, 2017, at 8:43 AM, Karl Wagner via swift-evolution >> <[email protected] <mailto:[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
Yeah, but by extension, every since compile-time flag is also an “axis of configuration”. What makes these few worthy of special language integration and compiler support? I think OS and architecture are both more fundamental and universal than whether you’re running on a simulator or real device. - Karl > >> >> 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 >>> <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] <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
