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

[Kevin Ballard]

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?

-Kevin Ballard

On Tue, Oct 18, 2016, at 09:39 AM, Nevin Brackett-Rozinsky via swift-evolution wrote:
> 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:
>
> let inMyPocket = $20
> let lochNess = £3.50
> let twoBits = 25¢
>
> if (inMyPocket - lochNess) > twoBits { … }
>
> 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.
>
> Nevin
>
>
> On Tue, Oct 18, 2016 at 12:19 PM, Dave Abrahams via swift-evolution
> <swift-evolution at swift.org> wrote:
>>
>> 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
>>
>> _______________________________________________
>>  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/20161019/1ad453e9/attachment.html>