[Review] SE-0087: Rename lazy to @lazy


(Chris Lattner) #1

Hello Swift community,

The review of "SE-0087: Rename lazy to @lazy" begins now and runs through May 23. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.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


(Chris Wagner) #2

* 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?

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?


(Brent Royal-Gordon) #3

  https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md

The proposal says this at the beginning:

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?

···

--
Brent Royal-Gordon
Architechies


(TJ Usiyan) #4

* 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:

https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.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-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(Trent Nadeau) #5

* 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:

https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.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


(Leonardo Pessoa) #6

The review of "SE-0087: Rename lazy to @lazy" begins now and runs through May 23. The proposal is available here:

        https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md

        * What is your evaluation of the proposal?

I have nothing against lazy as a keyword but I also like there is a
rule/policy to keep keyword/attribute consistency so I'd give it a go.

        * 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?

None.

        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading.


(Chéyo Jiménez) #7

  * 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

···

(Ash Furrow) #8

* What is your evaluation of the proposal?

I’m -1 on this. The only motivation given for the proposal is:

Swift's rule for attribues/keywords is that keywords usually modify type of variable; attributes do not.

Chris Lattner has [refuted this](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017905.html):

the proposal is incorrect in this claim

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:

https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.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


(Brent Royal-Gordon) #9

  * 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.

  * 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.

···

--
Brent Royal-Gordon
Architechies


(Chris Lattner) #10

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:

  https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md

The proposal says this at the beginning:

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?


(Austin Zheng) #11

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.


(Krystof Vasa) #12

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

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