<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>I'm actually vaguely surprised that the other currency symbols are considered valid identifiers, since they're not alphanumeric symbols. As for turning them into operators, it's a cute idea, but it doesn't work for any symbol that's used by multiple countries. For example, would $3.50 be USD, AUD, CAD, or any of the other dozens of countries that use dollars?<br></div>
<div><br></div>
<div>-Kevin Ballard</div>
<div><br></div>
<div>On Tue, Oct 18, 2016, at 09:39 AM, Nevin Brackett-Rozinsky via swift-evolution wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div>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:<br></div>
<div><br></div>
<div>let inMyPocket = $20<br></div>
<div>let lochNess = £3.50<br></div>
<div>let twoBits = 25¢<br></div>
<div><br></div>
<div>if (inMyPocket - lochNess) &gt; twoBits { … }<br></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.<br></div>
<div><br></div>
<div>Nevin<br></div>
<div><br></div>
</div>
<div><div><br></div>
<div defang_data-gmailquote="yes"><div>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">swift-evolution@swift.org</a>&gt;</span> wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;" defang_data-gmailquote="yes"><div><span><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 '$' 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 "if it wasn't there, would you add it to the language?". Of<br> &gt; course, it has been blessed by time, and it has *become* Swifty, by usage<br> &gt; because it'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't think it's un-swifty by any measure.&nbsp; It's not particularly</div>
<div> beautiful, I agree, but what would make a better, extremely terse, way<br></div>
<div> to refer to a posiitional parameter of a closure?&nbsp; Unless we can think<br></div>
<div> of something that's obviously better, then it is thoroughly swifty: a<br></div>
<div> pragmatic solution for an important problem.&nbsp; Unless we can think<br></div>
<div> of something that's obviously better, then it certainly *is* what we<br></div>
<div> would have added to the language.<br></div>
<div> <span><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't seen much of that.<br> &gt;<br> &gt; Now for the elephant in the room: '$' 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;</div>
<div> <span><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.&nbsp; It means</div>
<div> there are magic identifiers that are usable in all contexts but given<br></div>
<div> special meaning in some contexts.&nbsp; I think making the lexical roles of<br></div>
<div> various currency symbols more consistent is a worthy goal, but I'm not<br></div>
<div> sure this is the way to do it.<br></div>
<div> <span><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's cultural bias here, it's a bias based on programming language</div>
<div> precedent. \$[0-9] has a long history of use as a positional parameter<br></div>
<div> identifier in programming languages.&nbsp; Swift very explicitly embraces<br></div>
<div> *that* sort of “cultural bias.”&nbsp; The culture of programmers matters.<br></div>
<div> <span><span class="colour" style="color:rgb(136, 136, 136)"><br> --<br> -Dave<br> </span></span></div>
<div><div><div><br></div>
<div>______________________________<wbr>_________________<br></div>
<div> swift-evolution mailing list<br></div>
<div> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div>
</div>
</div>
</blockquote></div>
</div>
<div><u>_______________________________________________</u><br></div>
<div>swift-evolution mailing list<br></div>
<div><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</blockquote><div><br></div>
</body>
</html>