[swift-evolution] [Review] SE-0190: Target environment platform condition

[Graydon Hoare]

> On Nov 20, 2017, at 4:17 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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

>> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171127/0b068983/attachment.html>