"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."
backticks are just a "hack", with the proposal 0001 (Allow (most) keywords as argument labels), your proposal, we just will not see this feature being used. It's not just a matter of style, just does not seem natural. Expand type annotation to "pick" the correct function, as I said before, seems to me more natural. Or choose another symbol of course. Em seg, 28 de dez de 2015 às 17:49, Douglas Gregor via swift-evolution < [email protected]> escreveu: > > > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
