[swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Nevin Brackett-Rozinsky]

I strongly oppose the proposed mass-removal of operator characters. It
would be a major loss to the Swift language if that were to occur even
temporarily.

The long-term goal is for Swift to adopt the official Unicode guidance for
operator characters, which is still under development. Therefore I believe
we should make only minor and obvious changes right now, because there is
no sense in “jumping the gun” and causing unnecessary source-breaking
changes.

In particular, we should make it clear that Swift will most likely adopt
the Unicode operator conventions when they become available, so people are
aware and prepared.

When the time comes, we should deprecate any operator characters that
Unicode recommends against (unless we have a good reason not to), before
removing them in the next major release. The deprecation period ensures
that source-breaking changes result in a warning at first, so developers
have time to adapt.

I just went through all the valid operator characters in Swift, and the
only ones I would recommend to eliminate at this time are:
U+2800 – U+28FF (Braille patterns)
U+3021 – U+3029 (Hangzhou numerals)
U+2205 and U+221E (Empty set and Infinity)

Additionally, I propose to *add* one operator that is missing:
U+214B (Turned ampersand)

• • •

As for the rest of the proposal, I suppose normalizing identifiers and
dealing with confusable characters in a sensible way.

Regarding emoji, I look at them rather like the “I’m feeling lucky” button
on Google—essentially nobody uses it, but when they tried getting rid of it
people didn’t like the result. So I agree with Brent about that we should
keep them for cultural, not technical, reasons.

• • •

Returning to the discussion of operators, I am reminded of what happened
when we eliminated argument labels from functions passed as parameters. The
intent was and still is to reinstate them in a more robust manner.

However, during the interim the result has been a regression that goes
against the core tenets and philosophy of Swift. I would not want to repeat
that while waiting for official Unicode operator guidelines.

So I am strongly—adamantly—opposed to the operator-eviscerating portion of
this proposal.

We should make Braille characters, Hangzhou numerals, the empty set and the
infinity sign into identifiers. All other operators should remain as they
are until official Unicode recommendations exist, at which point we should
deprecate as necessary.

Nevin



On Wed, Oct 19, 2016 at 5:53 PM, Matthew Johnson via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> IMO, the best argument against using unicode symbols for operators defined
>> by mathematics is that they are currently difficult to type.
>>
>
> And there is no realistic hope of that changing. This issue is so
> compelling that C and C++ introduced standardized text-ascii alternatives
> for the punctuation operators to relieve stress on non-english keyboard
> users.
>
>
> I don’t agree that there is no realistic hope of that changing.  It
> appears to be pretty reasonable to anticipate that we’ll all be using
> software-driven keyboards that can display software-defined symbols on the
> keys in the relatively near future (probably 5 years, certainly 10).  All
> kinds of interesting things become possible when that happens, including
> the ability to make unicode operators much easier to discover and type in a
> programmer’s editor.
>
>
> _______________________________________________
> 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/20161019/959920f0/attachment.html>