on Mon Oct 17 2016, Jean-Denis Muys <email@example.com> 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.
> 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.
swift-evolution mailing list