On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
