[swift-evolution] [Pitch] Richer function identifiers, simpler function types

[Pyry Jahkola]

> On 28 Apr 2016, at 14:37, Tino Heth <2th at gmx.de> wrote:
> 
>> C1: Extend SE-0021 <https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md> by adding the underscore-in-parentheses syntax `foo(_)` to refer to the zero-argument function #1.
> I don't think that's consistent with the other use cases of the underscore: Afair, it never means "nothing", but always "there is something, but ignore it"

Right, that was another choice I forgot to justify:

We already refer to `func foo(_ x: Int, _ y: Int)` as `foo(_:_:)` even if the function call only contains a comma and no colons nor underscores. Yes, `func foo()` neither has an underscore in the definition. But we need something to distinguish its from the function call `foo()`, so `foo(_)` is an honest attempt to stick to the existing SE-0021 practice.

Personally, I'm fine with the syntax introduced by SE-0021 and I'd rather keep its criticism out of this thread if possible.

However, we could consider the alternative that you proposed where `foo` alone may only refer to the zero-argument function and for everything else, the argument list is always required.

> (…) so unless I didn't miss any downsides of using square brackets, (…)
> 
> let f = foo
> let f = foo[x: Int]
> let f = foo[Int]
> let f = foo[(Int, Int)]
> let f = foo[x: Int, y: Int]
> let f = foo[x: Int, y: Int]

The square brackets do avoid the ambiguity too but FWIW, they look foreign to me. It's also pretty noisy having to spell out all the argument types (unless you meant that it's optional doing so). In the majority of cases, there is no overloading by type, or if there is then the type can be inferred at the point of use.

— Pyry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160428/ce243f87/attachment.html>