# Problems with deprecations of islower, lowercase, isupper, uppercase

**URL:** <https://discourse.julialang.org/t/problems-with-deprecations-of-islower-lowercase-isupper-uppercase/7797>\
**Category:** Internals & Design\
**Created:** [December 15, 2017, 8:19pm UTC](https://discourse.julialang.org/t/problems-with-deprecations-of-islower-lowercase-isupper-uppercase/7797 "2017-12-15T20:19:32Z")\
**Posts on this page:** 1\
**Showing post:** 177

<div class="post-metadata">

**Author:** ![ScottPJones](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scottpjones/32/146_2.png) [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)\
**Post date:** [December 28, 2017, 11:54pm UTC](https://discourse.julialang.org/t/problems-with-deprecations-of-islower-lowercase-isupper-uppercase/7797/177 "2017-12-28T23:54:31Z")

</div>

> [@StefanKarpinski](#):
>
> Quite the opposite: in order for generic programming to work in a sane way, one must be strict about each generic function implementing exactly one meaning with coherent, consistent behavior across all different input types.

Please try a thought experiment: You have a generic function, `+`. For numbers it gives one result if you add `0xff` and `0x1`, and the result is `0x00`. If you add 255 and 1, you get 256, not 0.  
Arithmetic on a `Float16`, `Float64`, `BigFloat`, `Dec128` will all give results that are different.

Why do you understand that case as being generic, but that `uppercase`, which is simply a mapping (just as the `+` operation maps from 2 values to a third value) is not generic?

I’ve never heard of anybody using Julia complain about those cases with numbers.

Julia has great facilities with the type system, and multiple dispatch, to be able to use the old C function names in a very generic fashion, with the ability to the results depend on 1) the character set of the string type, 2) the language/locale 3) and possibly even a custom mapping table (via a keyword argument, or an argument with a specific type, maybe `Locale`, `MappingTable`)  
It’s important to note that the _encoding_ is totally irrelevant to all of those functions.

Also note that the Unicode standard only provides _defaults_ for, but then goes on to say that locale/language specific mappings should really be used.

The Unicode standard is very explicit that things like uppercase transformations should be able to handle language specific issues such as the Turkish dotted and dotless i, and that “ß” should be uppercased to “SS” in German.

See:

> Q: Is all of the Unicode case mapping information in UnicodeData.txt?
> 
> A: No. The UnicodeData.txt file includes all of the one-to-one case mappings. Since many parsers were built with the expectation that UnicodeData.txt would have at most a single character in each case mapping field, the file SpecialCasing.txt was added to provide the one-to-many mappings, such as the one needed for uppercasing ß (U+00DF LATIN SMALL LETTER SHARP S). In addition, CaseFolding.txt contains additional mappings used in case folding and caseless matching. For more information, see Section 5.18, Case Mappings in The Unicode Standard.

and

> A: The Unicode Standard defines the default case mapping for each individual character, with each character considered in isolation. This mapping does not provide for the context in which the character appears, nor for the language-specific rules that must be applied when working in natural language text.

---

_[View the full topic](https://discourse.julialang.org/t/problems-with-deprecations-of-islower-lowercase-isupper-uppercase/7797)._