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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
