on Mon Oct 17 2016, Jean-Denis Muys <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
