[swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Dave Abrahams]

on Mon Oct 17 2016, Jean-Denis Muys <swift-evolution at swift.org> wrote:

> While I already tersely supported this proposal, following all the negative
> reactions, I feel compelled to revisit my position. The main reason is that
> it strikes me that most points of view so far, including mine, were really
> culturally short sighted, and far too much US-centric.
>
> I totally agree that '$' being use by one (or even several) piece of code
> is not reason enough to change the language. But I also think that it being
> used by only one piece of code is no reason to reject the change.
>
> Most of us, including me, have been blinded by two things:
>
> 1- the use of the $ sign in other programming languages
> 2- the use of the $ sign in Swift as a prefix for implicitly declared
> closure parameters
>
> I think this second use is not Swifty at all. It clearly (to me) would fail
> the litmus test "if it wasn't there, would you add it to the language?". Of
> course, it has been blessed by time, and it has *become* Swifty, by usage
> because it's a useful feature, despite the choice of its syntax being so
> ugly (to my non-american eyes).

I don't think it's un-swifty by any measure.  It's not particularly
beautiful, I agree, but what would make a better, extremely terse, way
to refer to a posiitional parameter of a closure?  Unless we can think
of something that's obviously better, then it is thoroughly swifty: a
pragmatic solution for an important problem.  Unless we can think
of something that's obviously better, then it certainly *is* what we
would have added to the language.

> Similarly, I believe the use of the $ in other language should not be a
> guide in the decision here, either positively, nor negatively. We may pay
> some mild attention to the concern that we should perhaps avoid some
> confusion. I haven't seen much of that.
>
> Now for the elephant in the room: '$' is a currency symbol. As such it
> should be handled like any other currency symbol. Thinking otherwise would
> be very culturally offensive.

<snip>

>
> In conclusion, I believe this proposal must be accepted, and actually
> expanded to include ¥, ¢, £, and also to make it explicit that currency
> symbols can be used in variable names as first and only character, as first
> of many characters, and at any position.
>
> This would make $0, $1, $2… legal variable names. I believe this is OK.
>
> What would happen to implicitly declared closure parameters then? Nothing.
> They would continue to be implicitly declared in the context of closures
> that do not declare their parameters explicitly, similarly to `self` being
> implicitly declared in the context of a class. A user willing to use $0
> there would be facing a name collision, which is OK.
>
> Note that such a change is purely additive: no legal source code today
> would fail with this change.

That is actually a relatively un-swifty answer in some ways.  It means
there are magic identifiers that are usable in all contexts but given
special meaning in some contexts.  I think making the lexical roles of
various currency symbols more consistent is a worthy goal, but I'm not
sure this is the way to do it.

> I hope that at the very least, I opened a new perspective on this proposal,
> and I hope we can find a way to be less culturally biased.

If there's cultural bias here, it's a bias based on programming language
precedent. \$[0-9] has a long history of use as a positional parameter
identifier in programming languages.  Swift very explicitly embraces
*that* sort of “cultural bias.”  The culture of programmers matters.

-- 
-Dave