<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 26, 2017, at 8:43 AM, Karl Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<br class=""><br class="">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).<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>Dave</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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, <a href="https://github.com/AzureAD/azure-activedirectory-library-for-objc/pull/673" class="">https://github.com/AzureAD/azure-activedirectory-library-for-objc/pull/673</a>)</div><div class=""><br class=""></div><div class="">- Karl</div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 26. Oct 2017, at 15:36, BJ Homer via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class="">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.<div class=""><br class=""></div><div class="">(This was at least true in iOS 9, and I haven’t seen any indication that it has changed.)<br class=""><br class=""><div class="">-BJ</div><div class=""><br class="">On Oct 26, 2017, at 5:43 AM, Karl Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div class="">I’m currently -1 on this, because I don’t think simulator/device is a worthwhile-enough distinction for a built-in condition.</div><div class=""><br class=""></div><div class="">- Are you maybe looking for a Debug/Release condition? Because we already have that, through compile-time variables (the “-D” option).</div><div class="">- Does your platform’s simulator/emulator expose any additional API? Great! Take a look at #canImport…</div><div class="">- Why else would you need to distinguish simulator/device, and why are OS and architecture not sufficient for that case?</div><div class=""><div class=""><br class=""></div><div class="">Karl</div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 25. Oct 2017, at 05:05, Graydon Hoare via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Hi,</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div>Proposal is here: <a href="https://gist.github.com/graydon/809af2c726cb1a27af64435e47ef4e5d" class="">https://gist.github.com/graydon/809af2c726cb1a27af64435e47ef4e5d</a><div class=""><br class=""></div><div class="">Implementation (minus fixits) is here: <a href="https://github.com/graydon/swift/commit/16493703ea297a1992ccd0fc4d2bcac7d078c982" class="">https://github.com/graydon/swift/commit/16493703ea297a1992ccd0fc4d2bcac7d078c982</a></div><div class=""><br class=""></div><div class="">Feedback appreciated,</div><div class=""><br class=""></div><div class="">-Graydon</div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>