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

John McCall rjmccall at apple.com
Sun Dec 27 18:09:23 CST 2015


> On Dec 27, 2015, at 4:02 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto: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.

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.

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


More information about the swift-evolution mailing list