<div dir="ltr">"<span style="font-size:13px;line-height:19.5px">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.</span>"<div><br></div><div><span style="font-size:13px;line-height:19.5px">backticks are just a "hack", </span><span style="line-height:19.5px">with the proposal 0001 (Allow (most) keywords as argument labels), </span><span style="line-height:19.5px">your proposal, we just will not see this feature being used.</span></div><div><br></div><div>It's not just a matter of style, just does not seem natural.<br><div class="gmail_quote"><div dir="ltr"><br></div><div dir="ltr">Expand type annotation to "pick" the correct function, as I said before, seems to me more natural. Or choose another symbol of course.<br></div><div dir="ltr"><br></div><div dir="ltr">Em seg, 28 de dez de 2015 às 17:49, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Sent from my iPhone<br>
<br>
> On Dec 27, 2015, at 8:34 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
>>> On Dec 27, 2015, at 4:27 PM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:<br>
>>><br>
>>> On Dec 27, 2015, at 4:15 PM, Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> wrote:<br>
>>><br>
>>> On Dec 27, 2015, at 4:09 PM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:<br>
>>>>> I’m a fan of good error recovery, but I don’t think it is a major concern here for two reasons:<br>
>>>>><br>
>>>>> 1) The most common case in a method will lack a label, and "thing.foo(_: “ and “thing.foo(:” are both unambiguously a curried reference.<br>
>>>>> 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.<br>
>>>>><br>
>>>>> 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.<br>
>>>><br>
>>>> The concern, I think, is that a messed-up normal call might look like a curried reference.<br>
>>>><br>
>>>> 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.<br>
>>><br>
>>> 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):<br>
>>><br>
>>> foo.#bar<br>
>>><br>
>>> 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:<br>
>>><br>
>>> foo.#bar(param1:param2:)<br>
>>><br>
>>> either.<br>
>><br>
>> Right. I really like this effect.<br>
>><br>
>> 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.<br>
><br>
> 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.<br>
<br>
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.<br>
<br>
> -Chris<br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div>