or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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
In favor. Attributes essentially function as adjectives, describing the declarations they are applied to. `nonescaping` and `nonreturning` are more adjective-like than `noescape` and `noreturn`, and thus are more appropriate names.
I don't find the term-of-art argument compelling for `noreturn`; it's a rarely used feature even in the languages that support it. But that's just me.
* Is the problem being addressed significant enough to warrant a change to Swift?
Yes. This is the time to clean these things up.
* Does this proposal fit well with the feel and direction of Swift?
Yes. We are currently in a big push to rationalize Swift naming, and this move is compatible with that push.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Most languages I've used are not really very good at assigning parts of speech to different categories of language constructs. Swift's focus on this kind of thing is refreshing.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick reading, plus contributions to the previous discussion.
-1. noreturn is a term of art that is googable, renaming will make it obscure imo specially since it is not that common in iOS code.
If the core team were to keep `noreturn` then `nonscaping` will be weird,
but then if `noescape` became the default then (the non negative ;-) `escaping` would make sense.
* Is the problem being addressed significant enough to warrant a change to Swift?
no.
* Does this proposal fit well with the feel and direction of Swift?
no.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
n/a
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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
I agree with Jose. I especially like the idea of making `@noescape` the
default with a new `@escaping` attribute. As I believed was mentioned in an
earlier review, this would also make the proposed `@noescape(once)` just be
`@once`. I'd be happy to write the proposal for that rename.
···
On Wed, May 25, 2016 at 12:43 PM, Jose Cheyo Jimenez via swift-evolution < swift-evolution@swift.org> wrote:
> * What is your evaluation of the proposal?
-1. noreturn is a term of art that is googable, renaming will make it
obscure imo specially since it is not that common in iOS code.
If the core team were to keep `noreturn` then `nonscaping` will be weird,
but then if `noescape` became the default then (the non negative ;-)
`escaping` would make sense.
> * Is the problem being addressed significant enough to warrant a
change to Swift?
no.
> * Does this proposal fit well with the feel and direction of Swift?
no.
> * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
n/a
> * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Are you talking about writing a proposal for @escaping or @once after it becomes feasible?
I haven't seen a proposal for making `noescape` the default. Do you think that is with in the swift 3 scope and goal of source braking changes?
This is where is I saw this first.
···
On May 28, 2016, at 10:18 AM, Trent Nadeau <tanadeau@gmail.com> wrote:
I agree with Jose. I especially like the idea of making `@noescape` the default with a new `@escaping` attribute. As I believed was mentioned in an earlier review, this would also make the proposed `@noescape(once)` just be `@once`. I'd be happy to write the proposal for that rename.
On Wed, May 25, 2016 at 12:43 PM, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org> wrote:
> * What is your evaluation of the proposal?
-1. noreturn is a term of art that is googable, renaming will make it obscure imo specially since it is not that common in iOS code.
If the core team were to keep `noreturn` then `nonscaping` will be weird,
but then if `noescape` became the default then (the non negative ;-) `escaping` would make sense.
> * Is the problem being addressed significant enough to warrant a change to Swift?
no.
> * Does this proposal fit well with the feel and direction of Swift?
no.
> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
n/a
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I meant writing a proposal for having noescape be the default with an
`@escaping` attribute to have different behavior. `@once` would be a
separate proposal and looks to be out of scope for Swift 3.0.
On Sat, May 28, 2016 at 3:21 PM, Cheyo Ximenez <cheyo@masters3d.com> wrote:
Are you talking about writing a proposal for @escaping or @once after it
becomes feasible?
I haven't seen a proposal for making `noescape` the default. Do you think
that is with in the swift 3 scope and goal of source braking changes?
On May 28, 2016, at 10:18 AM, Trent Nadeau <tanadeau@gmail.com> wrote:
I agree with Jose. I especially like the idea of making `@noescape` the
default with a new `@escaping` attribute. As I believed was mentioned in an
earlier review, this would also make the proposed `@noescape(once)` just be
`@once`. I'd be happy to write the proposal for that rename.
On Wed, May 25, 2016 at 12:43 PM, Jose Cheyo Jimenez via swift-evolution < > swift-evolution@swift.org> wrote:
> * What is your evaluation of the proposal?
-1. noreturn is a term of art that is googable, renaming will make it
obscure imo specially since it is not that common in iOS code.
If the core team were to keep `noreturn` then `nonscaping` will be weird,
but then if `noescape` became the default then (the non negative ;-)
`escaping` would make sense.
> * Is the problem being addressed significant enough to warrant a
change to Swift?
no.
> * Does this proposal fit well with the feel and direction of
Swift?
no.
> * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
n/a
> * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?