On Dec 27, 2015, at 4:09 PM, John McCall <[email protected]> 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.
-Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
