Pitch: Character and String properties

[Michael_Ilseman]

@millenomi

An obvious way would be to introduce .contains(_ character: Character). So, for instance: CharacterSet.uppercaseLetters.contains("C" as Character).

It is true that it cannot express all properties here (like isEmoji), but it’s still existing API that does the same thing as some of this proposal.

Unfortunately, this is not the same semantics as Character.isUppercased. You can see an explanation of the different notions of casing in Unicode in my post on the scalar properties thread. Character.isUppercased follows the 3rd notion of casing in that post, while Character follows the first.

@millenomi

Any new API entry point needs to be maintained, and I expect things tied to internationalization to require some amount of care to avoid regressions.

Sorry for all the questions; I want to cut to the root of your concern. Do you view a proliferation of properties on Character to be a greater cause of concern than elsewhere in the standard library? That is, the first part of the argument seems like a general statement regarding any addition to the Swift standard library, and I'm very interested in why you think properties on Character are different.

As far as being tied to internationalization, these properties are Swift-specific semantics defined in terms of Unicode.Scalar.Properties or operations on String, which are kept up-to-date through use of ICU (as well as needing to be kept up to date anyways).