> On Dec 27, 2015, at 4:15 PM, Chris Lattner <[email protected]> wrote: > > 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.
Right. I really like this effect. I’m not that bothered by requiring the backticks, especially because it generalizes well to non-member function references, which I’m not sure any sort of different-member-access syntax does. John. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
