[swift-evolution] [Pitch] Build configuration tests

[Xiaodi Wu]

I'm glad you've resurrected this idea. I think it's worth thinking about,
certainly. At the moment, I do have some thoughts, some of which I may have
already had but have now forgotten. They're more notions than objections,
but I'll share them as they are:

* The new integer protocols now provide `bitWidth` (note the spelling) on
all fixed-width integer types. Since Int is defined as 32 bits on 32-bit
platforms and 64 bits on 64-bit platforms, it is possible to write `if
Int.bitWidth == 64 { ... }`. It isn't a conditional compilation block as
written, but as I understand it, the compiler either already does or should
be able to make it effectively a compile-time conditional. The question
remains if an explicit conditional compilation feature with a subtly
different spelling makes possible significant additional use cases. I don't
know the answer, but I think it's worth re-considering in light of the new
protocols.

* The new integer protocols had one chunk sent back for revision, which
consist of the parts about endianness. I think it might be wise to see how
that plays out before considering a conditional compilation feature, for
the reason that we may end up with a scenario similar to the one with
`bitWidth`.

* I have concerns about `vendor`. I get that it (a) allows you to write
something much shorter than `os(macOS) || os(iOS) || os(tvOS)`; and (b)
lets you anticipate any future OS from the same vendor. But two issues that
come to mind here are as follows. (1) In the Apple world, there's one
vendor for multiple platforms, but in the Linux world, there'd be many
vendors for one platform. It's unclear to me _how_ one might use `vendor`
profitably when it's so different. Is the only or main practical use
envisioned here a shorthand for Apple platforms? If so, couldn't we cut the
pretense and just write `#if apple`? (2) I get that part of the motivation
is that Apple may introduce a new platform and they often re-use their
technologies, and it'd be nice to get your code working "for free" on a new
platform. However, it seems to me that this would be unwise as a language
feature. There are no guarantees at all about what a future Apple platform
will look like. In other words, if `vendor(Apple)` is to evaluate `true`
for every Apple OS, it is a meaningless condition, as Apple makes no
guarantees whatsoever about commonalities between its current and future
platforms, and one cannot reason at all about code written for such a
scenario.

* Intuitively, `interop` seems fine, but I don't have much experience with
Obj-C interop.

* I think a better option than testing the difference between `arch` and
`os` would be great for detecting a simulator. I also think--just to
bikeshed a little--we can save on having a new word for this: just have an
optional argument in OS, since we're really asking is this "iOS" really the
"iOS Simulator"? That is: `#if os(iOS, simulator)` vs `#if os(iOS,
device)`. We can even have the compiler reject conditions such as `#if
os(macOS, simulator)` if we want.


On Mon, Apr 24, 2017 at 3:07 PM, Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

> I'm going to throw this back out into the SE arena to see if there's still
> interest in these.
>
> https://github.com/apple/swift-evolution/pull/369
>
> It seems to me that many of these are already incorporated into the
> language as private calls, and would only need minimal coding. Given the
> extremely limited timeline and the high volume of list traffic, I'm looking
> for specific concerns (or benefits) you see in this pitch.
>
> Thank you,
>
> -- Erica
>
>
> _______________________________________________
> 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/20170424/9e50472d/attachment.html>