<div dir="ltr"><div dir="ltr" style="font-size:12.8px">Yes, to_upper and to_lower would be nice to have, but I think the most important is to_nfc().  to_nfc() and to_nfd() are the basis for unicode support, and for distinct string() type, incompatible with both lists and binaries.<div><br><div>About unicode atoms and nfc - are you ready to have atoms 'è' and 'è', which are actually both the same and different in the same time? The one of them is 2 byte long <span style="font-size:12.8px"> </span><span style="font-size:12.8px">in utf-8</span><span style="font-size:12.8px">, another is 3 bytes long. But it is still the same character, just in nfc and in nfd forms. Both variants are used in the wild by different editors.</span></div><div>It may look harmless in most cases, but wait until you hash the value and use the hash for the password check.<div><br></div><div>I myself born and live in a country with non-latin script, and use unicode every day in software, but allowing unicode atoms isn't the most important thing about supporting proper unicode in Erlang. </div></div></div></div><div class="" style="font-size:12.8px"></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-02 16:59 GMT+03:00 Dmitrii Dimandt <span dir="ltr"><<a href="mailto:dmitriid@gmail.com" target="_blank">dmitriid@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On Sat, Jan 30, 2016 at 9:04 PM, José Valim<br></span><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<<a href="mailto:jose.valim@plataformatec.com.br" target="_blank">jose.valim@plataformatec.com.br</a>> wrote:<br>
><br>
> With all that said, are there any plans of supporting UTF-8 encoded atoms on<br>
> Erlang R19? If the feature is desired but not planned, I would love to<br>
> contribute the compiler and bytecode changes above although I will likely<br>
> need some guidance. If that is an option, I would love to get in touch.<br>
><br>
<br>
It is not planned for OTP 19. IMO, the feature is desired,<br>
but it is probably too late for OTP 19.<br>
<br>
Extending the BEAM format is necessary but not sufficient.<br>
It is also necessary to make sure that other code in OTP<br>
doesn't break. <br>
<br></blockquote><div> </div><div><br></div></span><div>In order to try and derail the "omg why unicode in atoms" discussion, I have a more pressing questions: are there plans for expanding Unicode support elsewehere? Hoping for at least a subset of <a href="https://github.com/erlang-unicode/i18n" target="_blank">https://github.com/erlang-unicode/i18n</a> namely length, to_lower, to_upper etc. :)</div><div><br></div></div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>