[Pitch] Build configuration tests


(Erica Sadun) #1

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


(Xiaodi Wu) #2

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ben Rimmington) #3

Instead of:

	#if interop(objc)
	    // Code that depends on Objective-C
	#endif

Would the following be equivalent?

	#if canImport(ObjectiveC)
	    // Code that depends on Objective-C
	#endif

Could the `canImport(ObjectiveC)` test also replace the `vendor(Apple)` test?

-- Ben

···

On 24 Apr 2017, at 21:07, Erica Sadun 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.


(Erica Sadun) #4

It probably could replace that -- E

···

On Apr 24, 2017, at 7:59 PM, Ben Rimmington <me@benrimmington.com> wrote:

On 24 Apr 2017, at 21:07, Erica Sadun 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.

Instead of:

	#if interop(objc)
	    // Code that depends on Objective-C
	#endif

Would the following be equivalent?

	#if canImport(ObjectiveC)
	    // Code that depends on Objective-C
	#endif

Could the `canImport(ObjectiveC)` test also replace the `vendor(Apple)` test?

-- Ben


(Erica Sadun) #5

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 requests were community driven. I'd defer to the community to decide whether compile-time conditional blocks or runtime would be better here.

* 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`.

nod.

* 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.

At this point, I'm just probably going to backburner this as well. No one seems particularly interested in it.

-- E

···

On Apr 24, 2017, at 4:19 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Mon, Apr 24, 2017 at 3:07 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution