> On Oct 27, 2017, at 5:06 AM, Karl Wagner via swift-evolution
> <[email protected]> wrote:
>
> 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?
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.)
Swift's grammar for compilation conditions[1] provides three different types of
leaf node:
- Boolean literals
- Identifiers, representing user-provided ("-D") command-line flags
- Platform conditions, representing language version and 3 existing
target-triple components
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.
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.
-Graydon
[1]
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/compilation-condition
<https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/compilation-condition>
[2] https://reviews.llvm.org/D39143 <https://reviews.llvm.org/D39143>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
