<div dir="ltr">It seems natural to me that currency symbols should be operators. This would allow, for example, prefix and postfix operators that take a number and return a “Currency” instance:<div><br></div><div>let inMyPocket = $20</div><div>let lochNess = £3.50</div><div>let twoBits = 25¢</div><div><br></div><div>if (inMyPocket - lochNess) > twoBits { … }</div><div><br></div><div>Of course, the unnamed closure parameter identifiers would conflict with that use of the dollar sign. However, I think Anton has the right idea. We already use the number sign for compiler magic, so it would make sense to call the closure parameters #0, #1, etc. In my view those even read better than what we have now.</div><div><br></div><div>Nevin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 18, 2016 at 12:19 PM, Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
on Mon Oct 17 2016, Jean-Denis Muys <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> While I already tersely supported this proposal, following all the negative<br>
> reactions, I feel compelled to revisit my position. The main reason is that<br>
> it strikes me that most points of view so far, including mine, were really<br>
> culturally short sighted, and far too much US-centric.<br>
><br>
> I totally agree that '$' being use by one (or even several) piece of code<br>
> is not reason enough to change the language. But I also think that it being<br>
> used by only one piece of code is no reason to reject the change.<br>
><br>
> Most of us, including me, have been blinded by two things:<br>
><br>
> 1- the use of the $ sign in other programming languages<br>
> 2- the use of the $ sign in Swift as a prefix for implicitly declared<br>
> closure parameters<br>
><br>
> I think this second use is not Swifty at all. It clearly (to me) would fail<br>
> the litmus test "if it wasn't there, would you add it to the language?". Of<br>
> course, it has been blessed by time, and it has *become* Swifty, by usage<br>
> because it's a useful feature, despite the choice of its syntax being so<br>
> ugly (to my non-american eyes).<br>
<br>
</span>I don't think it's un-swifty by any measure. It's not particularly<br>
beautiful, I agree, but what would make a better, extremely terse, way<br>
to refer to a posiitional parameter of a closure? Unless we can think<br>
of something that's obviously better, then it is thoroughly swifty: a<br>
pragmatic solution for an important problem. Unless we can think<br>
of something that's obviously better, then it certainly *is* what we<br>
would have added to the language.<br>
<span class=""><br>
> Similarly, I believe the use of the $ in other language should not be a<br>
> guide in the decision here, either positively, nor negatively. We may pay<br>
> some mild attention to the concern that we should perhaps avoid some<br>
> confusion. I haven't seen much of that.<br>
><br>
> Now for the elephant in the room: '$' is a currency symbol. As such it<br>
> should be handled like any other currency symbol. Thinking otherwise would<br>
> be very culturally offensive.<br>
<br>
</span><snip><br>
<span class=""><br>
><br>
> In conclusion, I believe this proposal must be accepted, and actually<br>
> expanded to include ¥, ¢, £, and also to make it explicit that currency<br>
> symbols can be used in variable names as first and only character, as first<br>
> of many characters, and at any position.<br>
><br>
> This would make $0, $1, $2… legal variable names. I believe this is OK.<br>
><br>
> What would happen to implicitly declared closure parameters then? Nothing.<br>
> They would continue to be implicitly declared in the context of closures<br>
> that do not declare their parameters explicitly, similarly to `self` being<br>
> implicitly declared in the context of a class. A user willing to use $0<br>
> there would be facing a name collision, which is OK.<br>
><br>
> Note that such a change is purely additive: no legal source code today<br>
> would fail with this change.<br>
<br>
</span>That is actually a relatively un-swifty answer in some ways. It means<br>
there are magic identifiers that are usable in all contexts but given<br>
special meaning in some contexts. I think making the lexical roles of<br>
various currency symbols more consistent is a worthy goal, but I'm not<br>
sure this is the way to do it.<br>
<span class=""><br>
> I hope that at the very least, I opened a new perspective on this proposal,<br>
> and I hope we can find a way to be less culturally biased.<br>
<br>
</span>If there's cultural bias here, it's a bias based on programming language<br>
precedent. \$[0-9] has a long history of use as a positional parameter<br>
identifier in programming languages. Swift very explicitly embraces<br>
*that* sort of “cultural bias.” The culture of programmers matters.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
-Dave<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div>