> On 22 Feb 2017, at 21:25, Patrick Pijnappel <[email protected]>
> 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._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
