[Review] Naming Functions with Argument Labels

Evolution Announcements
1

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs through January 10th. The proposal is available here:

  swift-evolution/0021-generalized-naming.md at master · apple/swift-evolution · GitHub <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md&gt;

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

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Joe
Review Manager

2

Sorry, Mail mangled the link here, and the review runs through January 18th. Here's the corrected link:

-Joe

···

On Jan 13, 2016, at 9:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs through January 10th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md&gt;

3

  * What is your evaluation of the proposal?

I like it quite a bit.

It uses very readable syntax and covers most cases (I’m glad to see the backticks are gone). Requiring a typing context for disambiguation when the labels are not sufficient seems like a reasonable approach.

I would really like to see a solution for getter/setters in Swift 3 but agree that lenses are the right approach to that and it would be an independent proposal.

I agree that the general partial application syntax is unnecessary. It might be nice to have something a bit cleaner than $0 for shorthand in closures someday and _ might work for that, however it is an orthogonal topic.

  * 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

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

I read both drafts of the proposal and followed the discussion on the list.

4

  * What is your evaluation of the proposal?

As a developer using Swift in a large project, I’ve had a few situations where this proposal would have been useful. As the proposal states, you can always wrap the explicit call in a closure, but that’s more cumbersome and potentially not as efficient (I wonder if there’s a compiler optimization to replace the closure with the function it calls). To that end, I would love to see this in Swift.

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

I am by no means a compiler engineer, so I can’t speak to the level of effort to implement it compared to the benefit, but I do think it’s a clear benefit to Swift without a lot of impact on existing code, if any.

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

Yes. Incidentally, I’m already using this syntax in a book <Search; I’m writing that uses Swift; I refer to methods like setTintColor(_:) all the time.

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

I’ve read the discussion on swift-evolution, read the final proposal on GitHub, and run into this problem in the “real world.”

Jeff Kelley

SlaunchaMan@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; | jeffkelley.org <http://jeffkelley.org/&gt;

···

On Jan 13, 2016, at 12:16 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs through January 10th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md&gt;

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:

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Joe
Review Manager

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

5

  * What is your evaluation of the proposal?

This proposal does solve a real problem.
I have one concern about that proposal though: this is solving a compiler ambiguity, but I think it would introduce a "visual" ambiguity :
  let variable = function(arg1, argName: arg2) // function call
  let variable = function (_:, argName:) // assign function to a variable
Those who lines, despite being pretty close visually, are very different.
I have the feeling that it might make non-obvious pieces a bit harder to read. That could reduce swift readability.

Todays method (using a closure) is more verbose, but it is less ambiguous visually I think.
I would be happy to have this possibility, but not at the cost of code readability.

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

As a developper, I didn't encounter that situation a lot : I assign closures to variables much more than functions.
Nevertheless, the current situation sounds a bit like an incoherency between the way swift identifies methods internally and the way the developper can refer to methods. I am absolutely no expert in compilers, but can that be a flaw that would become problematic later on ? Sorry, I cannot say :-). But if it is, then the problem surely is significant enough to be addressed.

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

As explained before, I feel the syntax proposed in that evolution has a cost on readability, as it makes two very different things very similar visually.

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

I’ve read the discussion on swift-evolution and the final proposal on GitHub.
I have to say that I didn't even found a syntax that I could propose to avoid the visual ambiguity.

Jerome

···

Le 13 janv. 2016 à 18:16, Joe Groff via swift-evolution <swift-evolution@swift.org> a écrit :

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs through January 10th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md&gt;

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,

-Joe
Review Manager

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

6

* What is your evaluation of the proposal?

+1 What? it is not already part of the language :-) Seems pretty natural to me.

  * 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 you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

yes Obj-c does this so it should be familiar to objc users and not that hard for newer users.

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

Read proposal and some of the threads.

7

* What is your evaluation of the proposal?

I'm tentatively in favor. I think this solves a real problem, and I like
that it's re-using the same syntax that we already use to talk about
functions in documentation and discussions. I'm mildly concerned about
the visual ambiguity, and about the fact that if the parser encounters
`foo.bar(baz: qux` it doesn't know yet if "qux" is supposed to be an
expression (because it's a function call) or just a bare identifier
(because it's a function reference), and it can't know that until it
sees a colon. I'm also mildly concerned that this feature will make it
impossible to ever introduce a single colon as a valid character in an
expression that's not surrounded by delimiters (e.g. dictionary literals
are fine because of the delimiters), but I'm not sure if that's
something we'd ever want to do (note that introducing a double colon,
e.g. ::, is fine because that's not legal in a function reference).

Given that I think the ambiguity can be dealt with, and I don't think
the visual ambiguity is particularly bad, and I'd like to see this
problem have a solution, that's why I'm tentatively in favor of it.

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

I think so, yes.

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

Yes.

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

I have not. The languages I can think of that have similar types of
function references don't have infix method names (or don't even support
overloading).

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

A quick reading.

-Kevin Ballard

···

On Wed, Jan 13, 2016, at 09:16 AM, Joe Groff wrote:

8

  * What is your evaluation of the proposal?

I'm conflicted.

If there is even the slightest chance that a future version of Swift will ever add placeholder-based currying like `foo(1, bar: _)`, I strongly favor using an underscore-based syntax for this feature now. A placeholder-based currying syntax is a strict superset of this proposal's capabilities, so there's no reason to end up supporting three syntaxes; we can introduce the most sorely needed subset first and then make it more powerful later.

If there is absolutely no chance that placeholder-based currying will be added, even in Swift 4 or later, then I am in favor of this proposal.

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

On the whole, yes. It's definitely an annoyance that you can't always access the method variant you need.

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

Yes. It turns a common convention into running code.

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

I don't really have any relevant experience. I haven't worked with many languages that supported both overloading and method references.

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

I've followed and participated in the thread, and spent a day or two thinking about my review before I wrote it.

···

--
Brent Royal-Gordon
Architechies

9

Hi Joe,

Do you have a plan for selecting between class and instance methods with the same name?

—Nathan

···

On Jan 14, 2016, at 4:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs through January 10th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md&gt;

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,

-Joe
Review Manager

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

10

+1

I think it solves a real problem and solves it about as well as this particular problem can be solved at this time.

The syntax seems good-enough, as-proposed, to me.

···

On Jan 13, 2016, at 11:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs through January 10th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md&gt;

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,

-Joe
Review Manager

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

11

The review of SE-0021 "Naming Functions with Argument Labels" ran from January 13...18, 2016. The proposal has been accepted. We plan to introduce the new syntax in both 2.2 and 3.0, using Doug's implementation at https://github.com/DougGregor/swift/tree/se-0021-generalized-naming\. Support for the proposal was overwhelmingly positive. A number of contributors proposed an alternative syntax, using a placeholder in the argument value position:

let x = Foo.bar(_, bas: _)

with the idea that this could potentially generalize to partial application syntax. We don't think this is a good direction for Swift for a couple of reasons. Swift already has fairly compact syntax for forming closures over partially applied functions, { Foo.bar($0, bas: $1) }. It may not be everyone's aesthetic cup of tea, but this notation has several important advantages. The braces unambiguously delineate the boundaries of the closure, which is a subtle problem with Scala-like approaches. The braces also provide a visual cue that capture is occurring. The $n placeholders are also more general since they allow for reordering of arguments. '_' in particular is also a poor choice of placeholder, since in other contexts where it's used, it's meant as a "black hole" for value binding in patterns rather than as a placeholder for a meaningful bound value.

Another concern that was repeatedly raised was how to disambiguate overloads. We feel that contextual type disambiguation is sufficient for the use cases we envision. Cocoa's naming conventions already limit the amount of overloading that occurs in frameworks (though the Swift 3 renaming introduces more), and unapplied functions are generally used in contexts with adequate type context, such as parameters to higher-order functions. Introducing purpose-built syntax, such as interleaving types into the name like "Foo.(_: Int bar: String)", would increase the complexity and ambiguity of the feature for relatively little gain.

-Joe

12

  * What is your evaluation of the proposal?

This proposal does solve a real problem.
I have one concern about that proposal though: this is solving a compiler ambiguity, but I think it would introduce a "visual" ambiguity :
  let variable = function(arg1, argName: arg2) // function call
  let variable = function (_:, argName:) // assign function to a variable
Those who lines, despite being pretty close visually, are very different.
I have the feeling that it might make non-obvious pieces a bit harder to read. That could reduce swift readability.

FWIW, there are no commas in the compound names of this proposal. That last line should be:

  let variable = function(_:argName:) // assign function to a variable

In the case where there is a first argument label, it is visually close:

  let variable = function(foo:bar:)

one has to scan to the last ‘:’ to distinguish it from a call.

  - Doug

···

On Jan 13, 2016, at 12:08 PM, Jérôme Duquennoy via swift-evolution <swift-evolution@swift.org> wrote:

Todays method (using a closure) is more verbose, but it is less ambiguous visually I think.
I would be happy to have this possibility, but not at the cost of code readability.

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

As a developper, I didn't encounter that situation a lot : I assign closures to variables much more than functions.
Nevertheless, the current situation sounds a bit like an incoherency between the way swift identifies methods internally and the way the developper can refer to methods. I am absolutely no expert in compilers, but can that be a flaw that would become problematic later on ? Sorry, I cannot say :-). But if it is, then the problem surely is significant enough to be addressed.

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

As explained before, I feel the syntax proposed in that evolution has a cost on readability, as it makes two very different things very similar visually.

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

I’ve read the discussion on swift-evolution and the final proposal on GitHub.
I have to say that I didn't even found a syntax that I could propose to avoid the visual ambiguity.

Jerome

Le 13 janv. 2016 à 18:16, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs through January 10th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md&gt;

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,

-Joe
Review Manager

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

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

13

Should the proposal include an exclusion list where the disambiguation still need to be resolved by an explicit type declaration. The first is currently hidden in the detailed design, so easy to miss as an exclusion. I compiled the following list based on the previous thread and my understanding of the proposal

Referencing to a parameter less function variant

func foo() { print("foo") }
func foo(_ :Int) { print("foo(_:)") }
let fn: () -> () = foo

Referencing to a function variant which differ only by return type

func foo(_: Int) -> Int { print(" foo -> Int"); return 0 }
func foo(_: Int) -> Bool { print(" foo -> Bool"); return true }
let fn: (Int) -> Int = foo

Referencing to a function variant which have same labels but different parameter types

func foo(_: Int, value: Int) { print("foo Int") }
func foo(_: Int, value: Float) { print("foo Float") }
let fn: (Int, Float) = foo // Still ambiguous reference

The proposal could also highlight that the following is no longer ambiguous.

func foo(_: Int, Celsius: Int) { print("foo Celsius") }
func foo(_: Int, Kelvin: Int) { print("foo Kelvin") }
let fn: (Int, Celsius: Int) = foo // Still/was ambiguous reference
let fn: = foo(_:Celsius:) // Fixed by the proposal

I started to write this note based on the second draft, so I was looking for default parameter example, and there seem to be an issue

func foo(a: Int = 1, b: Int = 2) { print("foo(\(a),\(b))") }
let fn = foo
fn() // error: missing argument for parameter #1 in call
fn(10) // error: cannot convert value of type 'Int' to expected argument type '(Int, b: Int)'
fn(10,b:20)
fn(b:20) // error: missing argument for parameter #1 in call
// All the above work when using foo() instead of fn()

Dany

···

Le 13 janv. 2016 à 12:20, Joe Groff via swift-evolution <swift-evolution@swift.org> a écrit :

On Jan 13, 2016, at 9:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs through January 10th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md&gt;

Sorry, Mail mangled the link here, and the review runs through January 18th. Here's the corrected link:

https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md

-Joe

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

14

Hi Joe,

Do you have a plan for selecting between class and instance methods with the same name?

Excellent question! Swift’s overload resolution has some built-in preferences for picking static methods when referencing based on a metatype and for picking instance methods when referencing based on an instance, e.g.,

class X {
  static func f0() -> Int { return 0 }
  func f0() -> String { return "" }
}

let fn1 = X.f0 // () -> Int
let x = X()
let fn2 = x.f0 // () -> String

So one might have to conjure up an instance to force the instance method, or use type context to force the issue:

let fn3: (X) -> () -> String = X.f0

but it can be done without extra syntax.

  - Doug

···

On Jan 13, 2016, at 4:36 PM, Nathan de Vries via swift-evolution <swift-evolution@swift.org> wrote:

—Nathan

On Jan 14, 2016, at 4:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs through January 10th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md&gt;

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,

-Joe
Review Manager

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

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

15

* What is your evaluation of the proposal?

+1 Seems pretty natural to me.

  * 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 you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

yes Obj-c does this so it should be familiar to objc users and not that hard for newer users.

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

Read proposal and some of the thread.

16

Without posting a full review, I’ll just drop a note in favor of the proposed syntax (underscores for anonymous args, colons, no commas, typically formatted with no spaces). This is exactly what we settled on more or less by default when adding robust autolinking to Jazzy:

https://github.com/realm/jazzy/issues/328#issuecomment-152064809

This syntax is already widely used enough that I considered it an already established informal Swift standard at the time, and I’m not aware of any complaints about it from Jazzy users.

Cheers, P

17

* What is your evaluation of the proposal?

I am in favor of this proposal.

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

The proposal has a more narrow scope than the original, but I think it addresses the problem it is trying to solve which is the ability to name functions with argument labels unambiguously.

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

This new version is simpler than the original and the notation is elegant, concise and consistent with the Swift language. It does not address naming property getters / setters but I am guessing that is outside the scope of this proposal and being addressed by Lens.

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

I've used Objective-C which Swift integrates with extensively. This is very similar to the naming of selectors and for that reason I think it will work well for mapping method names between Objective-C and Swift.

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

I read the original proposal and a lot of the emails. I had my reservations about the notation originally proposed and specially the back ticks. I wasn't sure if I liked it. However, now that the proposal has a more narrow scope, and the notation has been changed, I think it strikes the right balance that Swift is known for: elegant, concise and consistent.

···

On Jan 13, 2016, at 12:20 PM, Joe Groff <jgroff@apple.com> wrote:

On Jan 13, 2016, at 9:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs through January 10th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md

Sorry, Mail mangled the link here, and the review runs through January 18th. Here's the corrected link:

https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md

-Joe

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

18

Just MHO:

I don't know if we would ever introduce placeholder based currying, but if we did, u would be pretty strongly against using _ as the placeholder (despite the precedence in other languages), and would rather use a different sigil.

_ in swift currently means "discard" of a value in a pattern, or the closely related "missing" for a parameter name. Expanding that to mean "unspecified value to be provided later" seems like it would dilute this meaning. Basically, it would cause the confusion you are concerned about, independently of this feature proposal.

-Chris

···

On Jan 14, 2016, at 12:14 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

If there is even the slightest chance that a future version of Swift will ever add placeholder-based currying like `foo(1, bar: _)`, I strongly favor using an underscore-based syntax for this feature now. A placeholder-based currying syntax is a strict superset of this proposal's capabilities, so there's no reason to end up supporting three syntaxes; we can introduce the most sorely needed subset first and then make it more powerful later.

If there is absolutely no chance that placeholder-based currying will be added, even in Swift 4 or later, then I am in favor of this proposal.

19

I'm a -1 because of the syntax, I think it's nice and concise, and
unambiguous, but while it's familiar to people used to ObjectiveC it's
closer to ObjectiveC syntax than it is Swift.

I would +1 this proposal if the syntax was like this:
    let fn1 = someView.insertSubview(_,aboveSubview:)
    let fn = someView.insertSubview(_,at:_) // optional _ if it's needed to
disambiguate

That syntax would allow it to be naturally extended to support partial
application (Like what Bartlomiej Cichosz suggests
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/004739.html&gt;
):
    let t1 = someView.insertSubview(_ , aboveSubview: ) // equivalent of
yours
    let t2 = someView.insertSubview(_ , aboveSubview:v1) // partial
application
    let t3 = someView.insertSubview(v0, aboveSubview:v1) // calling a
function

This syntax is not quite as concise, but is much less surprising and more
logical than yours:
    let u1 = someView.insertSubview( _*:* aboveSubview: ) // yours
    let u2 = someView.insertSubview( _, aboveSubview: v1) // partial
application
    let u3 = someView.insertSubview(v0, aboveSubview: v1) // calling a
function

The first *:* in u1 is jarring and differs greatly from the expected
syntax. Whether the partial application syntax is adopted or not; the
delimiters are different to what you use when declaring or calling a
function, the exception doesn't seem necessary.

···

On Thu, Jan 14, 2016 at 10:05 AM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

On Jan 13, 2016, at 12:08 PM, Jérôme Duquennoy via swift-evolution < > swift-evolution@swift.org> wrote:

* What is your evaluation of the proposal?

This proposal does solve a real problem.
I have one concern about that proposal though: this is solving a compiler
ambiguity, but I think it would introduce a "visual" ambiguity :
let variable = function(arg1, argName: arg2) // function call
let variable = function (_:, argName:) // assign function to a variable
Those who lines, despite being pretty close visually, are very different.
I have the feeling that it might make non-obvious pieces a bit harder to
read. That could reduce swift readability.

FWIW, there are no commas in the compound names of this proposal. That
last line should be:

let variable = function(_:argName:) // assign function to a variable

In the case where there is a first argument label, it is visually close:

let variable = function(foo:bar:)

one has to scan to the last ‘:’ to distinguish it from a call.

- Doug

Todays method (using a closure) is more verbose, but it is less ambiguous
visually I think.
I would be happy to have this possibility, but not at the cost of code
readability.

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

As a developper, I didn't encounter that situation a lot : I assign
closures to variables much more than functions.
Nevertheless, the current situation sounds a bit like an incoherency
between the way swift identifies methods internally and the way the
developper can refer to methods. I am absolutely no expert in compilers,
but can that be a flaw that would become problematic later on ? Sorry, I
cannot say :-). But if it is, then the problem surely is significant enough
to be addressed.

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

As explained before, I feel the syntax proposed in that evolution has a
cost on readability, as it makes two very different things very similar
visually.

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

I’ve read the discussion on swift-evolution and the final proposal on
GitHub.
I have to say that I didn't even found a syntax that I could propose to
avoid the visual ambiguity.

Jerome

Le 13 janv. 2016 à 18:16, Joe Groff via swift-evolution < > swift-evolution@swift.org> a écrit :

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs
through January 10th. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md&gt;

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,

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

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

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

20

Doug,

Given a struct like this:

struct MyStruct {
    func sampleMethod(arg1:String, arg2: Int) -> String {
        return "Hello"
    }
    func sampleMethod(arg1:String, arg2: Int) -> Int {
        return 42
    }
}

Would this force the following?

let myStruct = MyStruct()
let myStructFn1: (String, Int) -> String = myStruct.sampleMethod(_:arg2:)
let myStructFn2: (String, Int) -> Int = myStruct.sampleMethod(_:arg2:)

Thanks,
—David

···

On Jan 14, 2016, at 1:50 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 13, 2016, at 4:36 PM, Nathan de Vries via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi Joe,

Do you have a plan for selecting between class and instance methods with the same name?

Excellent question! Swift’s overload resolution has some built-in preferences for picking static methods when referencing based on a metatype and for picking instance methods when referencing based on an instance, e.g.,

class X {
  static func f0() -> Int { return 0 }
  func f0() -> String { return "" }
}

let fn1 = X.f0 // () -> Int
let x = X()
let fn2 = x.f0 // () -> String

So one might have to conjure up an instance to force the instance method, or use type context to force the issue:

let fn3: (X) -> () -> String = X.f0

but it can be done without extra syntax.

  - Doug

—Nathan

On Jan 14, 2016, at 4:16 AM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

The review of "Naming Functions with Argument Labels" begins now and runs through January 10th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md <https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md&gt;

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,

-Joe
Review Manager

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

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

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