> On Dec 27, 2015, at 4:02 PM, Chris Lattner via swift-evolution
> <swift-evolution@swift.org> wrote:
> On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
