# Adding Unicode properties to UnicodeScalar/Character **URL:** \ **Category:** Pitches\ **Created:** [January 30, 2018, 4:32am UTC](https://forums.swift.org/t/adding-unicode-properties-to-unicodescalar-character/9310 "2018-01-30T04:32:26Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![Michael\_Ilseman](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/michael_ilseman/32/44640_2.png) [@Michael\_Ilseman](https://forums.swift.org/u/Michael_Ilseman)\ **Post date:** [January 30, 2018, 5:31pm UTC](https://forums.swift.org/t/adding-unicode-properties-to-unicodescalar-character/9310/3 "2018-01-30T17:31:10Z")
Thank you for kicking this off! [https://github.com/allevato/icu-swift](http://icu-swift) seems like a great testing ground for this. > [@allevato](#): > > A design proposal to improve the state of Unicode properties in the standard library will need to explicitly state which properties will be supported (and by elimination, which will be omitted, if any). I won’t try to be exhaustive here in my first message, but to cherry-pick some examples, properties like Uppercase, Lowercase, and White\_Space are obvious candidates for inclusion. Something like Logical\_Order\_Exception that comes up less frequently on its own may not meet the bar that we decide to set. This is a great way to approach the task. We may want to expose all the raw information for sophisticated use cases, and selectively bless some queries for common use. > [@allevato](#): > > How should we design the APIs that expose these properties? This may be motivated by how many properties we decide to support above. If the number we support is small, then individual properties for each probably makes sense (isLowercase, isUppercase, isWhitespace, etc.). But if we end up supporting something closer to the full set of properties, would that bloat the API? Would we want to provide something enum-based like hasProperty(.lowercase) instead? That would reduce bloat but it would also be quite less discoverable and less familiar compared to the is\* APIs provided by Java, C, and others My vote is for `isLowercase`, etc., to be present directly for common use, semantically equivalent to something built on top of a more general facility. Much like a subset of those provided by icu-swift. > [@allevato](#): > > What applies to Unicode.Scalar and what applies to Character? I feel like this will end up being a case-by-case (all puns intended) tiny research project. > [@allevato](#): > > Properties that have sensible definitions for Characters but which are not derived solely based on the constituent Unicode.Scalars. For example, we expect users will want to ask “is a character lowercase”, but you can’t say a Character is lowercase if all of its scalars have Lowercase == true because if you have “a” + a combining accent mark, the combining accent has Lowercase == false. In specific cases like this (upper/lower/titlecase), Unicode defines specific algorithms for strings that we can apply to Character: a Character c is uppercase if toUpper(c) == c, and likewise for lower- and titlecase. Case is pretty tricky. Unicode defines at least 3 different levels of thinking about case, because of course it does. Old fashioned notions of case (such as in Java or CharacterSet) are based on general category, but that proved to not be very future-proof and skewed towards bicameral alphabets. The second level of case is from derived properties, which is likely what we'll want for `UnicodeScalar` at least. Relevant (trimmed) quote from the State of String thread: > [@State of String: ABI, Performance, Ergonomics, and You!](https://forums.swift.org/t/state-of-string-abi-performance-ergonomics-and-you/7397/8): > > CharacterSet’s builtins model older Unicode semantics than what we probably want to provide. E.g. CharacterSet.lowercaseLetters means general category “Ll”, while modern Unicode defines property Lowercase which includes more scalars. The Lowercase property vs CharacterSet.lowercaseLetters is equivalent to ICU’s u\_isULowercase [1] vs u\_islower [2], where the former is the modern recommended API. > > [1] u\_isULowercase: [ICU-docs - International Components for Unicode Docs | icu-docs](http://icu-project.org/apiref/icu4c/uchar_8h.html#a8321c9ba617ed00787f20c4b23a254bc) > > [2] u\_islower: [ICU-docs - International Components for Unicode Docs | icu-docs](http://icu-project.org/apiref/icu4c/uchar_8h.html#aa26a51b768147fbf34029f8141132815) > > [3] [https://docs.perl6.org/language/regexes#Backslashed,\_predefined\_character\_classes](https://docs.perl6.org/language/regexes#Backslashed,_predefined_character_classes) Finally, the third level are the String functions such as `isLowercase` and `isUppercase`. I don't know if this level is overkill on Character, but off-the-cuff it seems viable. There might be some decent fast-paths in the implementation we can use for common scenarios. AFAICT, `isLowercase` would return true for caseless graphemes, such as "7". I don't know what behavior we want to expose, e.g. perhaps a grapheme has to satisfy both Unicode's `isCased` and `isLowercase` for our Swift computed property `isLowercase`. Or we expose both and let the user sort it out. Really depends on the use. --- _[View the full topic](https://forums.swift.org/t/adding-unicode-properties-to-unicodescalar-character/9310)._