Adding Unicode properties to UnicodeScalar/Character

[Michael_Ilseman]

@allevato

I was thinking that some like GraphemeClusterBreakType might be useful, but since it looks like stdlib uses a grapheme-cluster-based break iterator to determine grapheme boundaries, I’m not sure whether it would be used internally or not.

Since the grapheme breaking rules themselves change from version-to-version, we can't have an implementation based on these properties.

@allevato

Throwing this out there: do you think anyone would object to having a new standard library specifically for advanced extensions to Unicode.Scalar, Character, and String, along with some new APIs? It could be distributed with the toolchain but as a separate library from libswiftCore, so only those who need it will link it in. The advantage here vs. doing it as a third-party library is that we still resolve much of the pain of linking to ICU for users, on both platforms: Apple OSes, where you have to link your own copy statically or get an App Store rejection; and Linux, where renaming makes using ClangImporter problematic with the system ICU libs.

This has been discussed in many different flavors (e.g. Large Proposal: Non-Standard Libraries - #42 by Michael_Ilseman), but in general I would expect such a thing to happen first as a package. As far as the Linux ICU pain, we could just ship a modern ICU on Linux with Swift rather than trying to rely on the OS's. Linux has the reverse situation where Swift code is typically newer than the OS's libraries.

@allevato

If that’s a viable path, we should consider it now before adding a lot of APIs to libswiftCore, so that we don’t end up with a strange delineation of those APIs.

If by all of ICU you also mean the CLDR, then rest assured that there will be plenty of unexposed well-delineated surface area ;-) I think UnicodeScalar properties within the stdlib is sensible.