[swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

[Xiaodi Wu]

On Mon, Feb 27, 2017 at 10:07 PM, Nevin Brackett-Rozinsky via
swift-evolution <swift-evolution at swift.org> wrote:

> I think the most important goal is to end up with the right set of
> operator and identifier characters for *Swift*. The Unicode guidelines are
> a useful tool for that purpose, and get us a long way toward where we want
> to be. However at the end of the day we should weigh our success by how
> well we have done for Swift, not by how rigidly we adhere to Unicode
> recommendations.
>
> Our treatment of emoji is a great example: the right thing for Swift is
> different from the right thing for Unicode, so we choose to do what works
> best for Swift. This proposal captures that very well.
>

In fact, I'm greatly dissatisfied with how this proposal captures emoji.
Having come up with that scheme, I suspect that it is deficient in subtle
or obvious ways that are not yet apparent to me. This is why I have asked
for feedback along those lines. Note that for emoji, too, I have
deliberately resisted the one-by-one inclusion of certain characters that
are excluded by Unicode categories, of which there are a (small) handful.
My very strong personal preference, though soundly rejected, would have
been to remove the security and forward compatibility headache of support
emoji altogether. It does not in my opinion hold its own weight.

Matching what Unicode does should be a means for us, not an end. A stepping
> stone we can use when it helps. Unicode’s categorizations should inform
> and guide out decisions, not constrain them.
>

Well, now we are talking about overarching principles. The aim of this
proposal is in fact to assert that Swift's identifiers and operators should
be rationalized in a way that is constrained by Unicode recommendations.
Just as Swift aims to provide full support for correct Unicode handling in
strings by default, this proposal aims to align the valid characters to
current and future Unicode recommendations as tightly as possible. It is
anticipated that it should break a very small amount of actual code (if
any). It permits Swift to evolve with new developments in Unicode in the
future essentially "for free." In exchange we accept imperfections in
Unicode as imperfections in Swift. I argue that we should do so because our
own imperfections in understanding international character sets will
necessarily be greater than that of Unicode experts working systematically.

With regard to the fact that reclassifying the infinity and empty set
> symbols would be a breaking change, that is all the more reason to do it
> now, for Swift 4, before it is too late. Those two characters have come up
> in every iteration of this discussion on Swift Evolution that I can recall,
> and I have not heard anyone argue that they ought to be operators. I think
> it is safe to consider them low-hanging fruit.
>

Disagree. As mentioned in the proposal, no attempt is made to expand the
set of valid identifier characters to include non-emoji pictographs or
symbols.  If we adopt your approach, infinity and empty set would be the
only non-emoji non-"human language" symbols deliberately allowed in
identifiers, an approach no more consistent that the previous proposal to
include only the cow and dog emoji. The alternative is to go through a vast
swath of symbols character-by-character to determine which is sufficiently
"noun-like" to be an identifier, as Unicode does not and (as far as I can
tell) will never expand UAX#31 to include such symbols among identifiers.

As I mentioned, it would be also be inconsistent to consider excluding only
these two characters and not related characters, such as variations on the
infinity symbol, from the set of valid operators. Very quickly, the
necessity of doing a character-by-character debate balloons to encompass
the entire character set. I continue to believe that this is absolutely the
wrong approach.


> Nevin
>
> _______________________________________________
> 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/20170227/fa9c3b51/attachment.html>