[swift-evolution] [Pitch] Allow trailing argument labels

[James Froggatt]

why not just require a leading dot, like an enum, rather than a colon?
less syntax to learn, and it still eliminates the extra type.

------------ Begin Message ------------ 
Group: gmane.comp.lang.swift.evolution 
MsgID: <E9B1A877-434D-4FC8-92BB-142152651A07 at haravikk.me> 


>On 22 Feb 2017, at 21:25, Patrick Pijnappel <patrickpijnappel-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
>
>To summarize, there's one ambiguous case we'd need to resolve:
>
>func foo(_ x: Int, reportingOverflow)
>func foo(_ x: Int, _ reportingOverflow: Bool)
>
>let reportingOverflow = true
>foo(5, reportingOverflow) // Ambiguous
>
>One solution is to make trailing argument labels syntactic sugar for a trailing void argument.
>That would allow breaking ambiguity by specifying it explicitly:
>
>foo(5, reportingOverflow: ())
>
>A related issue is the call-site ambiguity for the reader (less of a problem if Xcode highlighted argument labels).

Vladimir suggested that an alternative might be to use a leading colon to indicate that the label is for selecting a function only, which would solve the ambiguity issues. Of course this means it's much the same as using the single enum case trick, but at least this way it'd still be a proper language feature rather than a workaround, and no extra types are declared just to support it.

So you'd have something like:

func foo(_ x:Int, :reportingOverflow) { … }
func foo(_ x:Int, _ reportingOverflow:Bool) { … }

let reportingOverflow = true
foo(5, reportingOverflow) // Calls the second declaration of foo using the boolean argument
foo(5, :reportingOverflow) // Calls the first declaration of foo

It's still a little subtle, but the single-case enum that this feature would replace has the exact same problem. So long as the label is sufficiently descriptive it shouldn't be a very likely target for a naming collision.

I think the leading colon alternative is probably the one I'd favour, as a plain argument label probably isn't clear enough, so having an indicator is better overall. It means that as a feature it won't have any advantages over the single-case enum, except that you don't have to declare an unnecessary extra type (which needs to be documented somehow), so I think it's still worth having to make this capability part of the function signature proper.


------------- End Message -------------