> 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. -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
