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 > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
