Sent from my iPhone
> On Dec 27, 2015, at 8:34 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: > > >>> On Dec 27, 2015, at 4:27 PM, John McCall <[email protected]> wrote: >>> >>> 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. > > I’m bothered by it because it overloads backtick to mean two things: > keywords-as-names, and annoying-sequences-of-tokens-as-names. Either use > would be acceptable to me, but the fact that we have to support one nested > inside the other makes it pretty nasty. In the context of this proposal, I think of backticks as delimiters around a generalized name. It's a generalization of today's notion that it's an escaped identifier; more like an escaped name. > -Chris > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
