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

[Martin Waitz]

With the current difficulty to come up with an agreed set of identifies vs. operators, maybe we should really try to sidestep this issue entirely and study Jonathan Shapiro’s idea of using identifiers as operators.

— Martin

> Am 21.10.2016 um 22:10 schrieb Xiaodi Wu via swift-evolution <swift-evolution at swift.org>:
> 
> A few other thoughts:
> 
> * One of our (or at least my) overarching goals for this proposal is to refine identifier and operator sets by moving away from an ad-hoc character-by-character approach to a systematic treatment that relies on well-defined criteria to select blocks of characters for inclusion. My personal opinion is that reverting to discussions of individual characters, such as the turned ampersand, means we're simply re-shuffling the current set of identifier and operator characters to a different one, having failed to discover any systematic basis for doing so. I think one of the strongest parts of this proposal is the straight-up statement that identifier start characters shall be IDC_Start and identifier continuation characters shall be IDC_Continue, modulo a few ASCII characters that require special treatment in Swift.
> 
> * Particularly if the community insists on emoji being identifiers, we will have to critically evaluate how to proceed on that in tandem with operators, because there exist emojified operators and arrows, and certain emoji are encoded in blocks that are otherwise symbols, which Unicode is likely to deem as operators in the future. Moreover, IIUC, certain codepoints can be either emoji or non-emoji symbols and variant selectors can specify which they are, but in the absence of a variant selector *either* the emoji or non-emoji version can be correctly displayed depending on the platform. For some of these, the non-emoji version is either clearly or plausible an operator character. Therefore, without dealing *very* carefully with emoji and with operators at the same time, we are failing to address a key motivation of this proposal, which is to fix the incorrect separation between emoji operators and emoji identifiers.
> 
>