On 18 Oct 2016, at 08:25, Jean-Denis Muys via swift-evolution <swift-evolution@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).
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@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@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 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
