[swift-evolution-announce] [Accepted] SE-0021 Naming Functions with Argument Labels

[Joe Groff]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution-announce/attachments/20160120/2157093a/attachment.html>