[Review] SE-0097: Normalizing naming for "negative" attributes


(Chris Lattner) #1

Hello Swift community,

The review of "SE-0097: Normalizing naming for "negative" attributes" begins now and runs through May 30. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0097-negative-attributes.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


(Brent Royal-Gordon) #2

  * What is your evaluation of the proposal?

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.

···

--
Brent Royal-Gordon
Architechies


(Chéyo Jiménez) #3

  * 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 :wink: `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?

read the thread.


(Charlie Monroe) #4

As I've mentioned previously, noreturn seems like a universal term used in various languages - i.e. the function will reach a point of "no return".

I don't have a problem with nonescaping, though.

···

On May 24, 2016, at 8:06 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0097: Normalizing naming for "negative" attributes" begins now and runs through May 30. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0097-negative-attributes.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Trent Nadeau) #5

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 :wink:
`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?

read the thread.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau


(Chéyo Jiménez) #6

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.

https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md

···

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 :wink: `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?

read the thread.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau


(Trent Nadeau) #7

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.

The former change was mentioned by Chris Lattner in
http://article.gmane.org/gmane.comp.lang.swift.evolution/16896.

···

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?

This is where is I saw this first.

https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md

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 :wink:
`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?

read the thread.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

--
Trent Nadeau