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, 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 you 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
The whole rigamarole would be overkill, so: Absolutely. I see no good reason not to.
(As a future direction, we should try to see if we can't open plain variable and function references to using more keywords. For instance, I see no particular reason you couldn't write `default()` even without a dot in front of it; AFAIK the only place it can be used is inside a `switch` statement, and there only with a colon after it, which wouldn't otherwise be valid.)
I didn’t initially think I would care much one way or the other about this proposal, but I find that proposal 0001 has been really helpful in letting me use prepositions such as “for” and “in” as argument labels and I see the same natural applications in this proposal.
I think this does fit in well with the feel and direction of Swift and feel it’s a small enough change that it is a reasonable one for Swift.
I’m for it.
Daniel
···
On Apr 26, 2016, at 6:20 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Hello Swift community,
The review of "Allow (most) keywords in member references" begins now and runs through April 29th. 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, 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 you 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
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, 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?
+1 This change feels like a natural next step of SE-0001, and SE-0005 feels incomplete without it.
* Is the problem being addressed significant enough to warrant a change to Swift?
Yes. Without it the changes of SE-0005 would in a sense put us back to where we were before SE-0001
* Does this proposal fit well with the feel and direction of Swift?
Yes (see my evaluation of this proposal above)
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
No. I can’t think of any.
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A quick reading of this proposal and a quick reading of SE-0001 and SE-0005
···
On 26 Apr 2016, at 06:20, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
More information about the Swift evolution process is available at
+1
I think it's a good thing. I don't think that it would introduce any bad ambiguities for the human reader. E.g. "case .default:" may look like "default:", but so does "case .`default`:" - all other cases that I can think of don't seem to introduce any problems.
···
Am 26.04.2016 um 06:20 schrieb Chris Lattner via swift-evolution <swift-evolution@swift.org>:
Hello Swift community,
The review of "Allow (most) keywords in member references" begins now and runs through April 29th. 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, 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 you 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
On Tue, Apr 26, 2016 at 5:28 PM, Michael Peternell via swift-evolution < swift-evolution@swift.org> wrote:
+1
I think it's a good thing. I don't think that it would introduce any bad
ambiguities for the human reader. E.g. "case .default:" may look like
"default:", but so does "case .`default`:" - all other cases that I can
think of don't seem to introduce any problems.
> Am 26.04.2016 um 06:20 schrieb Chris Lattner via swift-evolution < > swift-evolution@swift.org>:
>
> Hello Swift community,
>
> The review of "Allow (most) keywords in member references" begins now
and runs through April 29th. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0071-member-keywords.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, 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 you 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