Adding Unicode properties to UnicodeScalar/Character

[Michael_Ilseman]

@allevato

The Properties struct wouldn’t be reusable verbatim for Character, since many of the properties defined on Unicode.Scalar only apply to single scalars, not to grapheme clusters. For example, isGraphemeBase and isGraphemeExtend only make sense for a single scalar.

@hartbit

That makes sense, that’s why I don’t strongly disagree with the proposal’s direction. I just feel like some of those properties feel so useful that I would have liked to have them more accessible on Scalar directly instead of always going through properties. But perhaps I’m overthinking this.

It's... a bit more complicated here. Unicode defines properties on scalars but almost nothing on graphemes. Any queries on Character would be Swift inventing semantics not part of the Unicode standard. I'm working on a pitch right now to expose some of these queries, but the semantics need careful consideration and need to be more "Swifty" than "Unicody". That is, their naming and usage in common Swift code should adhere to what something really means rather than whether a bit was set in the UCD.

These scalar properties have very specific semantics, and are helpful for many expert uses, but surfacing them in a "non-expert" namespace gives a false impression of linguistic correctness. For example, the "isEmoji" property on scalars is set for ASCII numbers, which might be part of an emoji sequence somewhere. Trying to "fix" the name is hard, as their semantics are often nothing more than "is the bit set in the UCD".

I think @xwu is right that their names as terms-of-art should reflect Unicode connotations rather than common Swift usage connotations (hence the "expert namespace" of Properties and highly technical documentation):

@xwu

Brief comment: for properties, especially the “is*” ones, it’d be nice to hew closer to the Unicode names—easier to find for those who are experienced in these details, and not really any less clear for those that aren’t, since no name will fully explain. These are definitely all terms of art.