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
through September 28, 2016. The proposal is available here:
Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at
or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:
Proposal link:
Reply text
Other replies
What goes into a review?
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?
···
On Fri, Sep 23, 2016 at 7:38 PM, Douglas Gregor <dgregor@apple.com> wrote:
More information about the Swift evolution process is available at
On 24 Sep 2016, at 09:19, Goffredo Marocchi <panajev@gmail.com> wrote:
Strong 1+, Swift would benefit from being abbot less dogmatic at compile time and allow for more runtime flexibility especially with regards to third party libraries.
The compiler construct is needed, but there are times where you want the flexibility to be there when the code runs on a particular device with a particular OS.
Sent from my iPhone
On 24 Sep 2016, at 00:38, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
Hello Swift community,
The review of SE-0141 "Availability by Swift version" begins now and runs through September 28, 2016. The proposal is available here:
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.)
Thanks for bringing this up.
Jordan
···
On Sep 26, 2016, at 10:06, Ben Rimmington via swift-evolution <swift-evolution@swift.org> wrote: