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
* 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?
Definitely, I completely agree that lazy fits as an attribute like the given examples
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
NA
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read the proposal. I use lazy often and this feels right even though I hadn't thought of it before.
···
--
Chris
On May 17, 2016, at 8:31 PM, Chris Lattner <clattner@apple.com> wrote:
* 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?
Swift's rule for attribues/keywords is that keywords usually modify type of variable; attributes do not.
[citation needed]
As far as I can tell, this is not true at all. Most declaration modifiers do *not* change the type of anything; as far as I can tell, only `mutating`, `nonmutating`, and possibly `optional` do. Meanwhile, several attributes—particularly `@noescape` and `@autoclosure`—*do* change the type. So where is this belief coming from?
* 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. Though, will this change when/if the behaviors proposal is accepted
and–if yes–how?
* If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
No
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Quick reading.
···
On Tue, May 17, 2016 at 11:31 PM, Chris Lattner <clattner@apple.com> wrote:
Hello Swift community,
The review of "SE-0087: Rename lazy to @lazy" begins now and runs through
May 23. The proposal is available here:
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
* What is your evaluation of the proposal?
+1
* Is the problem being addressed significant enough to warrant a
change to Swift?
Yes. It's more consistent, both with the rules for keywords vs. attributes
and with future improvements with property behaviors, as mentioned in the
proposal.
* 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?
"Wrapper" behaviors like this have been attributes in other languages I've
used, like Java.
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Read the proposal.
···
On Tue, May 17, 2016 at 11:31 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
Hello Swift community,
The review of "SE-0087: Rename lazy to @lazy" begins now and runs through
May 23. The proposal is available here:
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
-1. Too early to optimize this. I would also be opposed to renaming didSet/willSet to lowercased preemptively because of the sake of renaming.
I think property behaviors should declare their own naming and syntax conventions (and be accepted in a version of Swift) before we start changing these API.
* Is the problem being addressed significant enough to warrant a change to Swift?
No because we do not know what property behaviors would look like for sure.
* 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 read this proposal and other mail treads about API that will be affected by property behaviors like didSet/ willSet and lazy
It seems then that this is largely a stylistic change. If I recall correctly, early beta versions of Swift used @lazy before removing the @. Seems unwise to revert without sound motivation.
* Is the problem being addressed significant enough to warrant a change to Swift?
It’s a stylistic change, I don’t think there’s anything wrong with the current style, so I don’t think it’s addressing an actual problem, just a stylistic choice.
* Does this proposal fit well with the feel and direction of Swift?
Not particularly.
* 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 gave it a thorough reading and consideration. Admittedly I think the current style is better than the proposed @lazy, but that’s a subjective opinion.
···
--
Ash Furrow
Sent with Airmail
On May 17, 2016 at 11:31:53 PM, Chris Lattner via swift-evolution (swift-evolution@swift.org) wrote:
Hello Swift community,
The review of "SE-0087: Rename lazy to @lazy" begins now and runs through May 23. 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.
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'm in favor of this change *if* we are very sure that the syntax will not change again, even if `lazy` is reimplemented as a property behavior. If we are *not* sure of this, however, then I think it should stay as it is now, because the advantages of `@lazy` over `lazy` are *very* minor and we don't want change fatigue to set in.
* Is the problem being addressed significant enough to warrant a change to Swift?
These kinds of consistency issues are one of the things we're trying to clean up, so yes.
* Does this proposal fit well with the feel and direction of Swift?
Yes...if, and *only* if, this change will align it with the final name and spelling of the feature.
* 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?
Quick reading or two, plus lots of discussion on property behaviors.
Correct - the proposal is incorrect in this claim. Swift's typical policy is that attributes do *not* modify the type of the declaration, which is why Swift 1 and 2 have used “lazy” instead of “@lazy”.
-Chris
···
On May 17, 2016, at 9:14 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
Swift's rule for attribues/keywords is that keywords usually modify type of variable; attributes do not.
[citation needed]
As far as I can tell, this is not true at all. Most declaration modifiers do *not* change the type of anything; as far as I can tell, only `mutating`, `nonmutating`, and possibly `optional` do. Meanwhile, several attributes—particularly `@noescape` and `@autoclosure`—*do* change the type. So where is this belief coming from?
My opinion on this proposal is the same as Brent's. We should only implement it if the core team is sure that they want to use '@' syntax for property behaviors whenever that feature is proposed again.
Austin
···
On May 19, 2016, at 12:20 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
* What is your evaluation of the proposal?
I commented earlier, but didn't actually review.
I'm in favor of this change *if* we are very sure that the syntax will not change again, even if `lazy` is reimplemented as a property behavior. If we are *not* sure of this, however, then I think it should stay as it is now, because the advantages of `@lazy` over `lazy` are *very* minor and we don't want change fatigue to set in.
If lazy becomes @lazy, shouldn't dynamic become @dynamic as well? They both don't change the type as argued in the proposal, it only changes the way the value is accessed.
Krystof
···
On May 19, 2016, at 4:19 AM, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org> wrote:
* What is your evaluation of the proposal?
-1. Too early to optimize this. I would also be opposed to renaming didSet/willSet to lowercased preemptively because of the sake of renaming.
I think property behaviors should declare their own naming and syntax conventions (and be accepted in a version of Swift) before we start changing these API.
* Is the problem being addressed significant enough to warrant a change to Swift?
No because we do not know what property behaviors would look like for sure.
* 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 read this proposal and other mail treads about API that will be affected by property behaviors like didSet/ willSet and lazy