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

[Colin Barrett]

I’m a -1 on the original proposal. I can see the logic in doing things that way, but it’s really unclear to me why we need to act *now*. In fact it seems like waiting might be a better option, given the things mentioned upthread about revisions to the Unicode standard.

Also, I think the message quoted below is a promising direction worth exploring. How would something like this work in the front-end? Swift’s grammar currently distinguishes between operators and identifiers right?

-Colin

> On Oct 19, 2016, at 12:17 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I think this is a promising direction. Getting us in line with Unicode recommendations is an important first step, and being conservative about the treatment of operator characters and emoji is a good engineering approach, though certainly unfortunate in the short term for users who've adopted custom operators or found interesting uses for emoji identifiers in Swift 3 and earlier.
> 
> In the discussion about operators, I wonder whether it makes sense to formally separate "identifier" and "operator" characters at all. My hunch is that there isn't going to be any perfect categorization; there are so many symbols and scripts out there that it's going to be difficult to definitively characterize many symbols as "obviously" an operator or identifier. Not every developer has the mathematical background to even recognize common math operators beyond the elementary arithmetic ones. Something to consider would be to change the way operators work in the language so that they can use *any* symbols (subject to canonicalization, visibility, and confusability constraints), but require their use to always be explicitly declared in a source file that uses an operator outside of the standard library. For example, you would have to say something like:
> 
> import Sets
> import operator Sets.∪
> 
> to make the '∪' symbol available as an operator in the import declaration's scope. This would provide more obvious evidence in the source code of what tokens are being employed as operators, and lessen the need to have formally distinct identifier and operator character sets.
> 
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution