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