Sorry I was away last week, didn't see these review questions until now.
> On Nov 20, 2017, at 2:58 PM, Rod Brown via swift-evolution
> <swift-evolution@swift.org> wrote:
>> 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
>> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
