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

[Jean-Denis Muys]

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).

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.

So can I use € as an variable name in Swift? According to Xcode 8.1B3, yes.
Can I use any currency symbol as an variable name in Swift? According to
Xcode 8.1B3, not quite, but almost all of them.

According to Mac OS "Emoji and Symbols" browser, there are 37 currency
symbols in Unicode:

let currencyAndSymbols = "$€¥¢£₽₨₩฿₺₮₱₭₴₦৲৳૱௹﷼₹₲₪₡₫៛₵₢₸₤₳₥₠₣₰₧₯₶"
I tried every one of them as a variable name. All were accepted, except 3:
¥, ¢, £:

// let ¥ = 1 // error: expected pattern

Note the poor error message.

Here are 33 successful attempts:

let $ = 1

let € = 1

let ₽ = 1

let ₨ = 1

let ₩ = 1

let ฿ = 1

let ₺ = 1

let ₮ = 1

let ₱ = 1

let ₭ = 1

let ₴ = 1

let ₦ = 1

let ৲ = 1

let ৳ = 1

let ૱ = 1

let ௹ = 1

let ₹ = 1

let ₲ = 1

let ₪ = 1

let ₡ = 1

let ₫ = 1

let ៛ = 1

let ₵ = 1

let ₢ = 1

let ₸ = 1

let ₤ = 1

let ₳ = 1

let ₥ = 1

let ₠ = 1

let ₣ = 1

let ₰ = 1

let ₧ = 1

let ₯ = 1

let ₶ = 1

print("₶ = \(₶)")

print(₶+₶+₶)

And finally, there is the very weird Rial Sign: ﷼
It is ok to use it as an variable name too (again, according to Xcode8.1B3).
But when trying to use it, Xcode switches to right-to-left mode, which
makes for strange (for my occidental eyes) behaviour and display. All the
following is OK in Xcode:

// unusual Xcode right-to-left behavior with Rial Sign

let ﷼ = 21


print("﷼= \(﷼)") // will print ﷼= 21

Of course, this is just a data point, and Xcode8.1B3 should not be the
arbiter here. But I believe whether Swift accepts currency symbols as
variable names should be consistent. Either it accepts all of them, or it
includes all of them.

I see no reason to exclude them. On the contrary, it was a design feature
of Swift to relieve use from the shackles of the ASCII character set.

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.

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.

Jean-Denis

        * What is your evaluation of the proposal?

+1. However, it should be expanded to include all Unicode currency symbols.

        * Is the problem being addressed significant enough to warrant a
change to Swift?

Very much so, because it reveals a significant inconsistency in the way the
language handles characters for identifiers.

        * Does this proposal fit well with the feel and direction of Swift?

Very much so, considering the language made a point to support unicode
characters in identifiers, and '$' should behave consistently with the
other Unicode currency symbols.

        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

In the specific case, this is irrelevant. We are in territory only treaded
by Swift

        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

A lot of time. I read the proposal, all the answers, spent significant time
experimenting with Xcode.



On 16 October 2016 at 19:45, Jay Abbott via swift-evolution <
swift-evolution at swift.org> wrote:

> > * What is your evaluation of the proposal?
>
> I am against it.
>
> > * Is the problem being addressed significant enough to warrant a change
> to Swift?
>
> No - if this change were made it would be a regression. The rationale for
> removing it in the first place was and remains valid.
>
> > * Does this proposal fit well with the feel and direction of Swift?
>
> No, it goes in the opposite direction. $ is not valid as the first
> character of a user-defined identifier and therefore should not be a valid
> identifier by itself.
>
> Side-note: Personally I think $ as the first character of an identifier
> should be reserved for shorthand ways to do other things, in line with how
> it is currently used in Swift.
> If used consistently, programmers will know they are seeing a language
> shortcut. Allowing $ as an identifier would break some of the natural
> intuition a programmer is able to use when learning and reading Swift code.
>
> > * If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
>
> The proposal seems purely for the benefit of the Dollar library, which
> could work just as well with any other identifier. Code using the dollar
> library is reminiscent of some other languages and programming styles. This
> isn't really a comment about the proposal itself, more the motivation
> behind it.
>
> > * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> I read the proposal and was perplexed by it, so I looked into the Dollar
> library to try and understand the motivation behind the proposal. It is a
> clever library with some nice features and tricks, but in many ways it
> seems to be designed to enable programmers to write non-Swifty code in
> Swift. I can understand the frustration of the author and users of the
> library, but its functionality could be provided in a Swifty way using
> extensions and generics, and I think if those users embraced this they
> would ultimately appreciate the change. If not then they might as well
> stick to another language.
>
>
> On Sun, 16 Oct 2016 at 17:31 Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Proposal link:
>>
>>         https://github.com/apple/swift-evolution/blob/master/
>> proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
>>
>>
>>         * What is your evaluation of the proposal?
>>
>>
>> -1.
>>
>> The proposal does not actually provide motivation for keeping $ beyond
>> "the Dollar library already uses it".
>>
>> A more Swifty way for a library to introduce these operations would be
>> with extensions. Here are some suggestions, based off the first several
>> operations described in the library's readme:
>>
>> $.at → convenience subscript(Index...) for Collection
>> $.chunk → convenience function for Sequence
>> $.compact → flatMap{$0}
>> $.contains → already exists as Sequence.contains
>> $.cycle → convenience function for Collection
>> $.difference → convenience function on Collection, or just use Set
>> operations, or filter
>> $.each → exists as Sequence.forEach
>> $.every → extension on Sequence
>> $.factorial → convenience method or postfix operator for Integer
>> $.fetch → convenience function on Collection
>> and so on.
>>
>> It looks like the author's Cent <https://github.com/ankurp/Cent> library
>> is already taking this approach.
>>
>>
>>
>>         * Is the problem being addressed significant enough to warrant a
>> change to Swift?
>>
>>
>> Yes, but the change has already been made: removing $ as a valid
>> identifier ;-)
>>
>>
>>
>>         * Does this proposal fit well with the feel and direction of
>> Swift?
>>
>>
>> Not really. If anything, IMO, the dollar sign feels more like an operator
>> character. (However, it's probably here to stay in identifiers because of
>> closure parameters and LLDB variables.)
>>
>>
>>
>>         * If you have used other languages or libraries with a similar
>> feature, how do you feel that this proposal compares to those?
>>
>>
>> The Dollar library resembles the style of JavaScript libraries such as
>> jQuery or Underscore, but that isn't a positive thing in my mind — as
>> mentioned above, the Swift way of doing things is different.
>>
>>
>>
>>         * How much effort did you put into your review? A glance, a quick
>> reading, or an in-depth study?
>>
>>
>> Thorough reading of the proposal; brief glance at the library's readme on
>> GitHub.  Lots of time thinking about operator & identifier characters for a
>> forthcoming proposal.
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161018/85b979d3/attachment.html>