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

[Thorsten Seitz]

+1

-Thorsten 

> Am 20.10.2016 um 02:32 schrieb Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org>:
> 
> 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
> 
> _______________________________________________
> 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/20161028/f82f0b2a/attachment.html>