<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) &gt; 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">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</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 &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
<br>
&gt; While I already tersely supported this proposal, following all the negative<br>
&gt; reactions, I feel compelled to revisit my position. The main reason is that<br>
&gt; it strikes me that most points of view so far, including mine, were really<br>
&gt; culturally short sighted, and far too much US-centric.<br>
&gt;<br>
&gt; I totally agree that &#39;$&#39; being use by one (or even several) piece of code<br>
&gt; is not reason enough to change the language. But I also think that it being<br>
&gt; used by only one piece of code is no reason to reject the change.<br>
&gt;<br>
&gt; Most of us, including me, have been blinded by two things:<br>
&gt;<br>
&gt; 1- the use of the $ sign in other programming languages<br>
&gt; 2- the use of the $ sign in Swift as a prefix for implicitly declared<br>
&gt; closure parameters<br>
&gt;<br>
&gt; I think this second use is not Swifty at all. It clearly (to me) would fail<br>
&gt; the litmus test &quot;if it wasn&#39;t there, would you add it to the language?&quot;. Of<br>
&gt; course, it has been blessed by time, and it has *become* Swifty, by usage<br>
&gt; because it&#39;s a useful feature, despite the choice of its syntax being so<br>
&gt; ugly (to my non-american eyes).<br>
<br>
</span>I don&#39;t think it&#39;s un-swifty by any measure.  It&#39;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&#39;s obviously better, then it is thoroughly swifty: a<br>
pragmatic solution for an important problem.  Unless we can think<br>
of something that&#39;s obviously better, then it certainly *is* what we<br>
would have added to the language.<br>
<span class=""><br>
&gt; Similarly, I believe the use of the $ in other language should not be a<br>
&gt; guide in the decision here, either positively, nor negatively. We may pay<br>
&gt; some mild attention to the concern that we should perhaps avoid some<br>
&gt; confusion. I haven&#39;t seen much of that.<br>
&gt;<br>
&gt; Now for the elephant in the room: &#39;$&#39; is a currency symbol. As such it<br>
&gt; should be handled like any other currency symbol. Thinking otherwise would<br>
&gt; be very culturally offensive.<br>
<br>
</span>&lt;snip&gt;<br>
<span class=""><br>
&gt;<br>
&gt; In conclusion, I believe this proposal must be accepted, and actually<br>
&gt; expanded to include ¥, ¢, £, and also to make it explicit that currency<br>
&gt; symbols can be used in variable names as first and only character, as first<br>
&gt; of many characters, and at any position.<br>
&gt;<br>
&gt; This would make $0, $1, $2… legal variable names. I believe this is OK.<br>
&gt;<br>
&gt; What would happen to implicitly declared closure parameters then? Nothing.<br>
&gt; They would continue to be implicitly declared in the context of closures<br>
&gt; that do not declare their parameters explicitly, similarly to `self` being<br>
&gt; implicitly declared in the context of a class. A user willing to use $0<br>
&gt; there would be facing a name collision, which is OK.<br>
&gt;<br>
&gt; Note that such a change is purely additive: no legal source code today<br>
&gt; 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&#39;m not<br>
sure this is the way to do it.<br>
<span class=""><br>
&gt; I hope that at the very least, I opened a new perspective on this proposal,<br>
&gt; and I hope we can find a way to be less culturally biased.<br>
<br>
</span>If there&#39;s cultural bias here, it&#39;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>