The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.
When reviewing a proposal, here are some questions to consider:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Since there's been no on-list discussion, I'd like to mention that I think this is a nifty idea. Being able to easily isolate code for device-only environments has been a consistent win for me.
-- E
Ā·Ā·Ā·
On Nov 16, 2017, at 3:23 PM, Ted Kremenek via swift-evolution <swift-evolution@swift.org> wrote:
The review of "SE-0190 - Target environment platform condition" begins now and runs through November 24, 2017.
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.
When reviewing a proposal, here are some questions to consider:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
When reviewing a proposal, here are some questions to consider:
What is your evaluation of the proposal?
I think the functionality is good, but I would like to see some thought on what future values could be to see if this is the best name/structure.
If it is just going to be the concept of a simulator, then something like isSimulated() might be better. In the current form, I think we should have both āSimulatorā and āDeviceā as options.
I would also like to see something shorter than targetEnvironment(), but it is somewhat infrequently used, so it isnāt that big a deal. It is just compared to os() and arch(), this is kind of a beast. It is a power user thing, so maybe something like āenv()ā would work? I normally try to avoid abbreviations, but we have arch() as precedent. The word āSimulatorā should be what stands out...
Would Testing be a possible future environment?
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, Definitely!
Does this proposal fit well with the feel and direction of Swift?
Yes.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I guess Objective C had something like this as well, which was more powerful, but also more messy.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick Read
Ā·Ā·Ā·
On Nov 16, 2017, at 2:23 PM, Ted Kremenek via swift-evolution <swift-evolution@swift.org> wrote:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.
When reviewing a proposal, here are some questions to consider:
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?
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.
Ā·Ā·Ā·
On 17 Nov 2017, at 9:23 am, Ted Kremenek via swift-evolution <swift-evolution@swift.org> wrote:
Thanks,
Ted Kremenek
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
I would also like to see something shorter than targetEnvironment(), but it is somewhat infrequently used, so it isnāt that big a deal. It is just compared to os() and arch(), this is kind of a beast. It is a power user thing, so maybe something like āenv()ā would work? I normally try to avoid abbreviations, but we have arch() as precedent. The word āSimulatorā should be what stands out...
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?
I think the functionality is good, but I would like to see some thought on what future values could be to see if this is the best name/structure.
As mentioned in a bit more detail in the other email I just posted, this proposal is to reflect values that occur in the "environment" field of the target triple; therefore possible future values would only be those that occur in practice in different toolchain variants: different libcs, different ABIs, similar miscellaneous variation within a given arch-vendor-os triple.
If it is just going to be the concept of a simulator, then something like isSimulated() might be better. In the current form, I think we should have both āSimulatorā and āDeviceā as options.
Ah yes, I forgot to mention this in the "alternatives considered" section. An earlier draft did indeed include "device" as a synonym for non-simulator, but this was noted as conflicting with the way the environment field of triples actually works: it's optional and may be either empty or one of several specific values, of which 'device' is not an option. I.e. one does not specify non-simulator by saying arm64-apple-tvos-device, one simply says arm64-apple-tvos, and omits the -simulator 4th field.
I would also like to see something shorter than targetEnvironment(), but it is somewhat infrequently used, so it isnāt that big a deal. It is just compared to os() and arch(), this is kind of a beast. It is a power user thing, so maybe something like āenv()ā would work? I normally try to avoid abbreviations, but we have arch() as precedent. The word āSimulatorā should be what stands out...
As mentioned in the "alternatives considered" section, "env" or "environment" was considered, but several people noted this is very easily confused as a means to access environment variables in the compilation process, which this proposal is not.
Would Testing be a possible future environment?
I do not believe so, it's not a way people presently use the environment field of a target triple.
-Graydon
Ā·Ā·Ā·
On Nov 20, 2017, at 4:17 PM, Jonathan Hull via swift-evolution <swift-evolution@swift.org> wrote:
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, Definitely!
Does this proposal fit well with the feel and direction of Swift?
Yes.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I guess Objective C had something like this as well, which was more powerful, but also more messy.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
IMO, ātarget environmentā and āsimulatorā are clear and self-explanatory;
ādestinationā means nothing to me, and just because Xcode uses it in the
context of a GUI does not mean that it is the best solution. Iām very much
in favor of this proposal exactly as it is.
Ā·Ā·Ā·
On Mon, Nov 20, 2017 at 20:50 Ben Rimmington via swift-evolution < swift-evolution@swift.org> wrote:
> On 21 Nov 2017, at 00:17, Jonathan Hull wrote:
>
> I would also like to see something shorter than targetEnvironment(), but
it is somewhat infrequently used, so it isnāt that big a deal. It is just
compared to os() and arch(), this is kind of a beast. It is a power user
thing, so maybe something like āenv()ā would work? I normally try to avoid
abbreviations, but we have arch() as precedent. The word āSimulatorā
should be what stands out...