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

[Chris Lattner]

On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>> can be correctly parsed as a reference to insertSubview(_:at:). However, it breaks down at the margins, e.g., with getter/setter references or no-argument functions:
>> 
>> extension Optional {
>>   func get() -> T { return self! }
>> }
>> 
>> let fn1 = button.currentTitle.get   // getter or Optional<String>.get?
>> let fn2 = set.removeAllElements()   // call or reference?
> From what I remember, the bigger concern with allowing foo(bar:bas:) without backticks is parser error recovery. The unambiguity with call syntax depends on having the `:)` token pair at the end. The edit distance between foo(bar:bas:) and a call foo(bar: bas) or work-in-progress call foo(bar: x, bas: ) is pretty slight, and would be tricky to give good diagnostics for. If we felt confident we could give good diagnostics, I'd support removing the backticks.

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.

-Chris

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