[swift-evolution] [Proposal draft] Generalized Naming for Any Function

[John McCall]

> On Dec 27, 2015, at 4:15 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> On Dec 27, 2015, at 4:09 PM, John McCall <rjmccall at apple.com> wrote:
>>> I’m a fan of good error recovery, but I don’t think it is a major concern here for two reasons:
>>> 
>>> 1) The most common case in a method will lack a label, and "thing.foo(_: “ and “thing.foo(:” are both unambiguously a curried reference.
>>> 2) A common case of accidentally completing a nullary call (thing.foo() vs thing.foo) will produce a type error.  We already produce good QoI for an unapplied function - adding the inverse would be simple.
>>> 
>>> Further, it will be uncommon *in general* to form a curried reference, so error recovery doesn’t have to be perfect in all the edge cases.  As with other commenters, if it is at all possible to avoid the extra backticks, I’d really prefer that.
>> 
>> The concern, I think, is that a messed-up normal call might look like a curried reference.
>> 
>> My inclination would be to go the other way: if we get a syntax for this that we like, I think we should use it for *all* curried member references, and reject things like foo.bar in favor of foo.`bar`.  The ability to write foo.bar for a method has always struck me as more clever than wise, to be honest.
> 
> If you were to go that far, I’d suggest looking at this as a different version of the “." operator.  If you resyntax curried to something else like (just a strawman, intentionally ugly syntax):
> 
> 	foo.#bar
> 
> Then you’d get a nice property that the plain old dot operator always has to be fully applied.  This certainly would be a win for error recovery.  Also, if you did this, you wouldn’t need the backticks from doug’s proposal either for things like:
> 
> 	foo.#bar(param1:param2:)
> 
> either.

Right.  I really like this effect.

I’m not that bothered by requiring the backticks, especially because it generalizes well to non-member function references, which I’m not sure any sort of different-member-access syntax does.

John.