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@swift.org> wrote:
on Mon Oct 17 2016, Jean-Denis Muys <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).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@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