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

[Nevin Brackett-Rozinsky]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161018/393145b5/attachment.html>