[Review] SE-0046 Establish consistent label behavior across all parameters including first labels


(Chris Lattner) #1

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:

Thank you,

-Chris
Review Manager


(David Owens II) #2

What is your evaluation of the proposal?

A huge +1.

Is the problem being addressed significant enough to warrant a change to Swift?

Most definitely.

Does this proposal fit well with the feel and direction of Swift?

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

A lot actually. I've been arguing for this change for a while now, so I'm super happy to see an official proposal come through.

···

On Mar 11, 2016, at 10:01 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(William Dillon) #3

  • What is your evaluation of the proposal?

+1

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes, I believe so.

  • Does this proposal fit well with the feel and direction of Swift?

I think so. When Swift was a language focused on Cocoa and Obj-C replacement, it made sense, but I think Swift is more than that now.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I don’t recall using a language where this was an issue

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

Read the review and discussion on the mailing list, including the countering views.


(Chris Wagner) #4

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:

  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


(David Sweeris) #5

• What is your evaluation of the proposal?
+1… I have a dislike of special cases

• Is the problem being addressed significant enough to warrant a change to Swift?
Yes, imho

• Does this proposal fit well with the feel and direction of Swift?
Yes, imho

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
As much effort as it took to read the discussion thread, plus a few instances of contemplation while sipping coffee.

- Dave Sweeris

···

On Mar 11, 2016, at 12:01 PM, 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


(Brandon Knope) #6

What is your evaluation of the proposal?
+1! This makes it so much more consistent and easier to reason with

Is the problem being addressed significant enough to warrant a change to Swift?
Yes. I have also heard some students have trouble understanding the current behavior

Does this proposal fit well with the feel and direction of Swift?
Completely. More so than the current way

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
This makes swift more like swift than ObjC

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick reading but enough to understand the problem and proposal

Brandon

···

On Mar 11, 2016, at 1:01 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Haravikk) #7

  • What is your evaluation of the proposal?

I’m in favour of it; while I will most likely disable external parameter names for many of my methods that I feel are self explanatory, I think it’s better to consciously make that decision vs it being the default for first parameters.

  • Is the problem being addressed significant enough to warrant a change to Swift?

It’s not a major issue; people are free to set external labels if they wish, but it’s an inconsistency that could do with being removed (IMO).

  • Does this proposal fit well with the feel and direction of Swift?

Yes; it encourages consistency, and encourages a little thought before disabling all external parameter names on all parameters, rather than making the first a special case. It’s also easier to type underscore when you’re happy not to have a label, vs duplicating the name or coming up with another one to enable it.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

The bulk of my experience is with Java, Javascript and PHP where there are no parameter labels, and I hate that that was the case. Generally in Swift I like to have them except for very simple methods (or obvious first parameters) as well as tuple-like structs.

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

I’ve been following the discussion around this issue; quickly skimmed the proposal, but it seems pretty simple.

···

On 11 Mar 2016, at 18:01, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:


(Kenny Leung) #8

+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


(Curt Clifton) #9

The proposal is available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md

   • What is your evaluation of the proposal?

+1. The baroque set of rules for external parameter was one of the most confusing and frustrating parts of Swift 1. Swift 2 substantially improved on this situation. The proposed change will rationalize this part of the language, substantially reducing Swift's complexity.

   • Is the problem being addressed significant enough to warrant a change to Swift?

Definitely.

   • Does this proposal fit well with the feel and direction of Swift?

Yes. Swift 3 is about increasing power while reducing incidentally complexity. This is a strong contribution to the latter.

   • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I really appreciate that Swift follows Objective-C in using named parameters. This results in much more readable client code. That said, Objective-C's syntax necessitates combining the action part of a method's name with the first parameter label. Breaking with that is a sensible thing to do. Programmers will still retain the ability to suppress any external parameter name, including the first, so the expressive power of the language is unchanged.

Turning this question on its head, I've never used a language with parameter naming rules as complex as Swift's. This proposal rectifies that problem.

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

I read the proposal in detail twice. I've been bothered by the complexity of the external parameter rules since Swift was introduced, so the problem has been on my mind since WWDC 2014.

Cheers,

Curt

···

-------------------------
Curt Clifton, PhD Software Developer
The Omni Group
www.curtclifton.net


(Tikitu de Jager) #10

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md

• What is your evaluation of the proposal?

+1

• Is the problem being addressed significant enough to warrant a change to Swift?

Yes. It's a confusion for new Swift learners, especially those unfamiliar with Objective C, with increasingly little upside.

• Does this proposal fit well with the feel and direction of Swift?

Yes: it removes two special cases (first args work differently to other args; but not for inits) which fits the language goal of overall consistency, and it fits Swift's movement away from the constraints imposed by compatibility with Objective C conventions (instead supporting these by an increasingly smart translation layer).

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Python has a bit of both:
* a frequent idiom in which some initial parameters (not necessarily just the first) are called positionally (without names) followed by named parameters; but
* no expectation that the function/method name will give type information for those initial parameters.

In my Python, Java, Javascript & Objective C experience, Objective C is the only one with a strong expectation of moving parameter-typing information into function/method names, and also the only one that systematically singles out the *first* parameter.

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

I read the proposal carefully. I've skimmed the discussion, but haven't seen many arguments against: there may be something I'm missing there.


(Patrick Gili) #11

  • What is your evaluation of the proposal?

I like this proposal because it increases consistency. My experience trying to remember when to label or not to label started feeling like reading Macbeth.

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

Other languages that I have experience with do not have complex semantical rules that govern parameter labeling.

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

Quick read.

···

(Ben Rimmington) #12

Proposal link:

<https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md>

• What is your evaluation of the proposal?

+1

I believe it should be accepted for Swift 3.0

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

N/A

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

I followed previous threads (API design guidelines, etc.)

-- Ben


(Juan Ignacio Laube) #13

*What is your evaluation of the proposal?*

+1. I was waiting for this.

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

n/a

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

A lot. I think this was needed in a first place.

···

On Fri, Mar 11, 2016 at 3:01 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Daniel Steinberg) #14

+1

I am a big fan of this proposal.

In a function or method that has more than one parameter, I strongly favor the consistent use of labels.

For a function or method that has a single parameter, I don’t care whether we standardize on a label being required or not. It wouldn’t bother me that a function with a single parameter wouldn’t require a label for that parameter while an init with a single parameter would. I mention this because one of the reasons given for no label on the first parameter was that half of the functions in an audit had zero or one parameter. It is important to me that a function with multiple parameters requires labels for all of them.

As an aside, once we have this consistency, I would like guidance from Apple and support from Xcode on how to format these method definitions and calls if we place them on multiple lines (each parameter on a separate line). In Obj-C we lined up the colons, in Swift should we line up the colons, the first letter of the parameter label, something else? It’s not that I care what we choose, but it would be nice to have a consistent format that is supported by Xcode. Currently, if we indent in a way other than is supported by Xcode, subsequent lines are indented awkwardly.

Thanks,

Daniel

···

On Mar 11, 2016, at 1:01 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Pierre Monod-Broca) #15

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


(Trent Nadeau) #16

- What is your evaluation of the proposal?
   - Huge +1
   - Is the problem being addressed significant enough to warrant a change
   to Swift?
   - Yes. This creates a simpler, more consistent language.
   - Does this proposal fit well with the feel and direction of Swift?
   - Yes, especially after the new API guidelines.
   - 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've read through the preceding discussion, the proposal, and others'
      responses.

···

On Fri, Mar 11, 2016 at 1:01 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md

--
Trent Nadeau


(Charles Srstka) #17

+1

  • What is your evaluation of the proposal?

It’s probably needed. The inconsistency in the current rules for argument labels is rather ugly.

  • Is the problem being addressed significant enough to warrant a change to Swift?

I think so. This will make the language cleaner, as well as make it easier for newcomers to pick up.

  • Does this proposal fit well with the feel and direction of Swift?

I’d say so. In fact, it seems to fit Swift’s general aesthetic better than the current behavior.

  • 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 seen have all the arguments either labeled or unlabeled by default. Having the first argument treated differently is somewhat idiosyncratic, and this change would bring Swift more in line with other languages.

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

Quick reading.

Charles

···

On Mar 11, 2016, at 12:01 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:


(Brent Royal-Gordon) #18

  https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md

  • What is your evaluation of the proposal?

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.

(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. This has always been an ugly, complicated corner of the language, and previous efforts to simplify it have been rewarded.

  • Does this proposal fit well with the feel and direction of Swift?

Yes. It reflects the new API guidelines while making things simpler and consistent.

  • 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 have pretty simple (though often somewhat impoverished) parameter naming rules; Swift has always been oddly complicated in this way.

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

A quick reading and a little bit of participation in the discussion thread.

···

--
Brent Royal-Gordon
Architechies


(Adrian Kashivskyy) #19

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


(Charles Constant) #20

What is your evaluation of the proposal?

+1.

I'm delighted.

Is the problem being addressed significant enough to warrant a change to

Swift?

Absolutely. My experience with inconsistent argument labels, has not been
positive. It adds a pinch of uncertainty whenever I'm declaring functions,
and wastes time when I'm copying and pasting between init methods and
functions.

Does this proposal fit well with the feel and direction of Swift?

Yes, very well. Swift is supposed to be powerful, but easy for beginners.
The change will be helpful for casual users, and students. Fewer rules to
remember :slight_smile:

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?
A lot actually. I've been arguing for this change for a while now, so I'm
super happy to see an official proposal come through.

Very little effort, though I have followed related threads for weeks, and
there's no doubt in my mind I support the proposal.