<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 27, 2017, at 5:06 AM, Karl Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""></div>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?</div></div></blockquote><div><br class=""></div><div>The "environment" field is an optional 4th component of the (not-quite-accurately-named) target-triple. This is not new, it's a thing lots of toolchains have some more-or-less standard support for (different toolchains use it for different purposes: simulator-ness, ABI, libc variation, etc.)</div><div><br class=""></div><div>Swift's grammar for compilation conditions[1] provides three different types of leaf node:</div><div><br class=""></div><div> - Boolean literals</div><div> - Identifiers, representing user-provided ("-D") command-line flags</div><div> - Platform conditions, representing language version and 3 existing target-triple components</div><div><br class=""></div><div>There's currently no way to write a compilation condition that depends on the 4th field (environment) of the target-triple. This proposal is to surface that 4th field in the same place the other 3 fields are surfaces: as a platform condition.</div><div><br class=""></div><div>Conflated with this, the conversation in this thread seems to have ventured into asking -- independently of the question of how to express the environment field as a compilation condition -- whether it's right to express simulator-ness as a target-triple component at all, rather than as a preprocessor symbol. This ship has, however, already sailed: a patch expressing this choice entered LLVM a week ago[2], on the justification that the simulators are literally separate SDKs: from the perspective of the compiler, they're about as different as targeting different OSs.</div><div><br class=""></div><div>-Graydon</div><div><br class=""></div><div>[1] <a href="https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/compilation-condition" class="">https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/compilation-condition</a></div><div>[2] <a href="https://reviews.llvm.org/D39143" class="">https://reviews.llvm.org/D39143</a></div><div><br class=""></div></div></body></html>