Sorry I was away last week, didn't see these review questions until now.
What is your evaluation of the proposal?
I think itās good in theory, but I am concerned that there is currently only one example case of āsimulatorā, which also seems somewhat limited to Apple Platforms. Would another case ādeviceā make sense?
Also a few questions I have:
How would this be extended to make sense for each platform? Say on platforms that actually have an emulator (rather than a simulator) how would this apply to those cases?
How does it make sense for the desktop where we could compile on the platform, and there would *be* no simulator?
Could there be other relevant cases we can add at other times?
Would these cases only make sense for Platform Vendors or IDEs to manage?
The proposal is to track the "environment" field of target triples directly, as the existing platform conditions track the arch and os fields. Therefore I'll answer these questions -- in the context of this proposal -- in terms of target triples, which are typically defined and managed a few steps outside the Swift language, at the level of platform toolchains (i.e. including the C and C++ compiler, linker, runtime libraries, SDKs, etc.)
At present, many but not all details of target triples are surfaced in Swift platform conditions. For example, the difference between "arm" (32bit) and "arm64" is surfaced in values accepted by the the "arch()" platform condition of Swift, but the difference between various 32bit arm sub-architectures (eg. armv7s vs. armv7k) is not surfaced. In theory this could be, but I think it hasn't come up as a requirement for anyone yet to build Swift code that's conditional on that difference (and not conditional on a more salient difference, like OS).
The "environment" field of the target triple is used, in practice, to mean many different things; it's an "optional disambiguation" field when there are two or more targets that are meaningfully-different at a toolchain level (eg. separate SDKs, target libraries, runtimes or such) but that are not otherwise differentiated in the first 3 fields of the triple (arch, vendor, OS).
So, for example, with respect to question #1, if one has a platform that supports "emulator" as an environment component of the triple, and users had any interest in inspecting or switching on it, Swift could meaningfully surface that value here in the future.
The current set of values used in the environment field _in LLVM_ is a bit of a grab bag of "not otherwise specified" dimensions of target variation: ABI specifications ("eabi" vs. "gnueabihf"), runtime libraries ("musl"), execution engines ("opencl", "coreclr"), or other miscellaneous software-environment switching ("gnu", "android", "cygnus"). It's also used in some contexts to switch between different object file formats. There is not presently a target environment that uses "emulator" and I suspect if one wanted to start, they might recycle "simulator" just to avoid adding near-synonyms.
In any case, I don't expect all of these to need to surface as values in the proposed targetEnvironment platform condition, but if any were to need to surface, the idea would be to just pass the name of the environment field through to the condition, as with "simulator".
With respect to question #2, the behaviour of Swift code that's conditional on "#if targetEnvironment(simulator)" would be the same on a target with no simulator variants as it would be when targeting the non-simulator variant of a target that has a simulator variant: the condition would evaluate to false, since the 4th (environment) field of the triple would not be equal to "simulator". Note that independent of this proposal, not every combination of fields in a triple is meaningful: one cannot (say) compile for s390x-unknown-PS4 because despite all 3 fields being piecewise valid, no such combined target exists (to my knowledge), or certainly not in any toolchain I've seen. The behaviour will depend on whether or not toolchain support actually exists for some target in question; and at the Swift level, it is equally legal to compose a platform condition that will never be true on a given toolchain -- eg. "#if arch(s390x) && os(PS4)" -- because it specifies a combination of target triple values that isn't supported.
With respect to #3, yes, other values could surface, I think I actually addressed this above.
Finally with respect to #4, this proposal isn't intended to dictate who or what adds new fields to triples, merely provide an outlet for such values to be surfaced (and to surface one that users are already switching on). The values that wind up in the "environment" field of a triple are determined by means outside the scope of this proposal (typically platform vendors submitting support for an environment to a toolchain, yes, but not exclusively).
-Graydon
Ā·Ā·Ā·
On Nov 20, 2017, at 2:58 PM, Rod Brown via swift-evolution <swift-evolution@swift.org> wrote:
Does this proposal fit well with the feel and direction of Swift?
I think it makes sense to clean this up. The current checks are remarkably obscure and full of unsafe assumptions it would be good to sort out. But Iād like to see this solution fleshed out to a solution that is appropriate beyond the iOS/tvOS/watchOS ecosystems.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
No, but I have run into the same problems documented here in Obj-C and Swift.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A quick reading.
Thanks,
Ted Kremenek
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution