SE-290 (second review): Unavailability Condition

[tkremenek (Ted Kremenek)]

Accepted with Revision

Aside: The review period for SE-0290 ended a while back, so this review conclusion is long delayed. For that, I apologize profusely both to the proposal author and all those that participated in the review discussion. When I took on managing the review I did not sufficiently anticipate how my time would be so pressed with other concerns. It is something I'll better assess in the future when scheduling reviews that I manage.

SE-0290 is accepted with revision. The sole revision is that the * syntax be dropped from the @unavailable predicate. There was a lot of great discussion that led to this insight. I'm particularly appreciative to @James_Dempsey nicely framing the rationale:

@James_Dempsey

Even without understanding the precise meaning of the wildcard character, the fact that platforms other than iOS all resolve to true makes sense in the statement:

if #available(iOS 13.0, *)

The wildcard can be understood as ‘match or consider available every version of every other platform’. Therefore, for a non-specified platform this always resolves to true. I believe this is clear even to developers without deep knowledge of the mechanics of #available.

I understand the logic in the proposal that leads to the wildcard resolving to false. I also agree that non-specified platforms always resolving to false is the desired behavior.

if #unavailable(iOS 13.0, *)

However, I think people will find this spelling confusing, since a wildcard traditionally matches everything. I realize there is the suggestion to clarify this in the documentation, but I believe fighting against the widely understood meaning of a wildcard will lead to confusion.

Personally, I would favor a spelling without the wildcard:

if #unavailable(iOS 13.0)

I can think of this spelling as:

If compiling for iOS, this resolves to true if iOS 13.0 is unavailable. No other platform is referenced, either explicitly or via wildcard, so no other platform is considered and therefore no other platform can resolve to true.

There was some general concern about what @available means for writing cross-platform code:

@bjhomer

Maybe this can all be resolved with a change of name . We’ve tied ourselves into knots over “what does #unavailable(iOS 14) mean on Linux?”, which is clearly a contentious question.

This was something I wrestled with as well, and was the primary reason it took me so long to circle back.

The @available feature, as it is designed today, is not sufficient to write all conditional logic to support platform-dependent code. Swift contains various #if predicates for this purpose, including #if os(...), #if arch(...), and so on.

The primary purpose of @available, as it exists today, is to be able to write code that can run on different versions of the same OS, and take advantage of newer APIs when they are available. The key example for Swift today is deploying apps to Apple platforms, where a downloaded app is designed to run on different releases of (say) iOS, but leverage different features and capabilities depending on the OS release. In that regards, this proposal addresses an ergonomic expressivity hole in the language to write such logic. The defined behavior in the proposal for the composition of #unavailable is conservatively defined as well, which will encourage @unavailable to be used in relatively easy to reason about cases.

The discussion on this proposal generated a tremendous amount of signal. There is a point where possibly the broader design of availability checking and cross-platform code could undergo a fresh re-think. In the meantime, SE-0290 is an incremental improvement in the existing model that will benefit users.

Thank you to everyone who participated in this review.