On Fri, Mar 11, 2016 at 1:27 PM, Chris Wagner via swift-evolution < swift-evolution@swift.org> wrote:
*What is your evaluation of the proposal?*
A huge +1.
*Is the problem being addressed significant enough to warrant a change to
Swift?*
Absolutely, named parameters are immensely beneficial
*Does this proposal fit well with the feel and direction of Swift?*
100%
*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?*
A fair deal, read the proposal. I’ve also been annoyed for awhile by the
omission of the first param name in my development that I often explicitly
add it.
On Mar 11, 2016, at 11:01 AM, Chris Lattner <clattner@apple.com> wrote:
Hello Swift community,
The review of “Establish consistent label behavior across all parameters
including first labels” begins now and runs through March 15, 2016. The
proposal is available here:
or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:
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 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:
it makes more sense and is more consistent and constructers require a first param it is a bit surprising that regular methods are different. Plus you can still omit the label on first param if it makes sense. However, leaving out the param with this proposal is visually less appealing so people may be more tempted to add parameter labels than have underscores.
• 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?
Perhaps.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Most other languages don’t do this so it is a bit of a surprise that Swift does, but it is perhaps a distinguishing characteristic and the current way makes people think a bit more perhaps about what their direct object is.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
On Sat, Mar 12, 2016 at 3:32 PM, Kenny Leung via swift-evolution < swift-evolution@swift.org> wrote:
+1 from me. The previous convention was good for Objective-C syntax, but
feels unnatural for the more function-like syntax. I think this will make
things better for people coming in from other languages.
-Kenny
> On Mar 11, 2016, at 10:01 AM, Chris Lattner <clattner@apple.com> wrote:
>
> Hello Swift community,
>
> The review of “Establish consistent label behavior across all parameters
including first labels” begins now and runs through March 15, 2016. The
proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.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. When replying, please try to keep the proposal link at the
top of the message:
>
> 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 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
> Review Manager
> _______________________________________________
> swift-evolution-announce mailing list
> swift-evolution-announce@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
On Sat, Mar 12, 2016 at 4:09 PM Pierre Monod-Broca via swift-evolution < swift-evolution@swift.org> wrote:
• What is your evaluation of the proposal?
In favor
• Is the problem being addressed significant enough to warrant a change
to Swift?
Yes : the problem is significant without being overwhelming, and the
solution seems rather simple.
• Does this proposal fit well with the feel and direction of Swift?
Yes, it increases consistency. Both between the first parameters and the
others, and between a function declaration and its signature.
It was one of the first think to bother me in Swift.
• If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
Not really.
• How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
I read the proposal, and rather quickly parts of the discussion.
As I mention in the proposal, I consider subscripts distinct, playing a different role in the language.
I do not have any problem with the existing implementation or their optional labels.
-- E
···
On Mar 13, 2016, at 3:35 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
I think it's a great idea. In previous versions of Swift, the inconsistent treatment of function parameters was justified—barely—by the fact that standard Swift style left most arguments unlabeled. Now that the API guidelines now call for many functions to label their first parameters, this justification has been fatally weakened.
Now that we're going to have consistent rules everywhere else, I think the design team should also consider applying the same rules to subscripts. Unlike functions, subscripts still *do* usually have unlabeled first parameters, but they are written so rarely that I'm not sure it's worth being inconsistent with literally every other parameter construct in the language.
Strong +1 from me. The first negative though I had when starting Swift the first day it came out was about the inconsistency of function/method/initializer argument names.
Is the problem being addressed significant enough to warrant a change to Swift?
Absolutely.
Does this proposal fit well with the feel and direction of Swift?
Definitely.
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 through the entire thing and have wanted this exact change from the first day I looked at the language. I highly support it.
···
> What is your evaluation of the proposal?
Strong +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?
Fits very well. Anonymous first parameters are a relict of Objective-C and do not conform to new API Naming Guidelines.
> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick read of the proposal document.
Pozdrawiam – Regards,
Adrian Kashivskyy
> Wiadomość napisana przez Chris Lattner via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>w dniu 11.03.2016, o godz. 19:01:
> Hello Swift community,
>
> The review of “Establish consistent label behavior across all parameters including first labels” begins now and runs through March 15, 2016. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.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. When replying, please try to keep the proposal link at the top of the message:
>
> 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 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
> Review Manager
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
All subscript parameters _are_ unlabelled by default.
There are also different rules for:
* operator functions (which cannot have argument labels);
* closure parameters (which cannot have parameter names).
-- Ben
···
On 13 Mar 2016, at 21:35, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
Now that we're going to have consistent rules everywhere else, I think the design team should also consider applying the same rules to subscripts. Unlike functions, subscripts still *do* usually have unlabeled first parameters, but they are written so rarely that I'm not sure it's worth being inconsistent with literally every other parameter construct in the language.
(Alternatively, making all subscript parameters unlabeled would be a simpler rule than the current one, and would suit multi-dimensional subscripts pretty nicely.)
• Is the problem being addressed significant enough to warrant a
change to Swift?
Yes. In my experience, newcomers to Swift are often confused by parameter
labels in general, and first parameters in particular, and they often get
them wrong on their first few attempts.
• Does this proposal fit well with the feel and direction of Swift?
Yes, it fits well with Swift's API Design guidelines, especially "Clarity
is more important than brevity" and "Clarity at the point of use".
• If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
I have not used any languages that handle parameter labels quite like Swift
does.
• How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
Quick read. I'm ashamed to admit that I missed the other threads discussing
this.
···
On Fri, Mar 11, 2016 at 10:52 PM, Paul Ossenbruggen via swift-evolution < swift-evolution@swift.org> wrote:
• What is your evaluation of the proposal?
it makes more sense and is more consistent and constructers require a
first param it is a bit surprising that regular methods are different. Plus
you can still omit the label on first param if it makes sense. However,
leaving out the param with this proposal is visually less appealing so
people may be more tempted to add parameter labels than have underscores.
• 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?
Perhaps.
• If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
Most other languages don’t do this so it is a bit of a surprise that Swift
does, but it is perhaps a distinguishing characteristic and the current way
makes people think a bit more perhaps about what their direct object is.
• How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
(Alternatively, making all subscript parameters unlabeled would be a simpler rule than the current one, and would suit multi-dimensional subscripts pretty nicely.)
All subscript parameters _are_ unlabelled by default.
Huh, so they are. My mistake.
Well, consider that an illustration of how infrequently subscripts are used, and how familiar people will be with their special parameter rules. :^)