The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

What is your evaluation of the proposal?
+1
Is the problem being addressed significant enough to warrant a change to
Swift?
Yes
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 think that holds up well.
How much effort did you put into your review? A glance, a quick reading, or
an in-depth study?
A quick read of the proposal.

Hello Swift community,

The review of SE-0141 "Availability by Swift version" begins now and runs

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

Good question. The “Versioned API” design is for testing a run-time property—it’s asking whether, dynamically, a particular library version is available (#available) or can be assumed available (@available) across the whole process. Since the Swift 4 compiler will use one runtime and standard library whether it’s in 3 mode or 4 mode, checking a run-time property isn’t the semantics we want. This proposal is concerned with the Swift language version at the time of compilation, and only for this particular module. (That’s also why there’s no #available component to the proposal.)