I'm not at all convinced ambiguity is a real problem, in this case.
The event of this realistically being ambiguous is as unlikely as two otherwise identical functions accepting two different enum types, as well as those two enum types sharing a particular case name. This just doesn't happen in good code (or even bad code).
I've yet to see any real benefit to new syntax. This whole branch of conversation started out with the possibility we could drop the leading dot through making this a language feature, and now that's been shown impractical. All the alternatives that have since been suggested have been *more* syntactically heavyweight, and it seems like we're forgetting why we wanted to remove the dot in the first place.
If one goal of Swift is clarity at the point of use, and the resulting syntax of this feature is less readable than the original enum version, then I'd argue the proper Swift solution is still going to be to create an enum.
There's no point making it unambiguous and clear when this feature is being used, if that is what drives people away from actually using it.
------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <DE897398-6BEA-41BE-BA96-724638FFDFC7@icloud.com>
Hi everyone, this is my first post, hopefully I get the formatting and everything right...
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.
I think this could lead to ambiguity if the trailing argument label was also an enum case, and there was a function signature whose last argument type was that enum. E.g.,
enum E {
case trailing
}
func foo(_ i: Int, trailing: E) {}
func foo(_ i: Int, trailing) {}
Now, which version of foo gets called by foo(1, .trailing)? It's a contrived example but demonstrates a real problem.
Since the dollar sign is so rarely used ― correct me if I'm wrong, but its only current use is for positional closure arguments ― I propose we use it for trailing arguments. The fact that it seems out of place in a function context makes its intention clear ― unlike, say, a colon which definitely "belongs" within a function's parentheses, or a period which can go just about anywhere.
The syntax I propose would be the following:
// Define
func foo(_ i: Int, $trailing) {}
// Call
foo(1, $trailing)
It's not exactly pretty, but it's certainly unambiguous and makes the intention clear.
------------- End Message -------------