<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 22, 2016, at 5:09 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Thu, Sep 22, 2016 at 6:54 PM, Michael Gottesman <span dir="ltr" class=""><<a href="mailto:mgottesman@apple.com" target="_blank" class="">mgottesman@apple.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Sep 22, 2016, at 4:19 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">You mean values of type String?</div></div></blockquote><div class=""><br class=""></div></span><div class="">I was speaking solely of constant strings.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""> I would want those to be exactly what I say they are; NFC normalization is available, if I recall, as part of Foundation, but by no means should my String values be silently changed!</div></div></blockquote><div class=""><br class=""></div></span><div class="">Why.</div></div></div></blockquote><div class=""><br class=""></div><div class="">For one, I don't want to pay the computational cost of normalization at runtime unless necessary.</div></div></div></div></div></blockquote><div><br class=""></div><div>This would only happen with strings that are known to be constant at compile time (and as such the transformation would occur at compile time). There would be no runtime cost.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> For another, I expect to be able to round-trip user input. </div></div></div></div></div></blockquote><div><br class=""></div><div>String checks for canonical equivalence, IIRC.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Normalization is not lossless and cannot be reversed. Finally, if I want to use normalization form D (NFD), your proposal</div></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> would make it impossible, because (IIUC) serial NFC + NFD normalization can produce different output than NFD normalization alone.</div></div></div></div></div></blockquote><div><br class=""></div><div>Why would you want to do this/care about this? I.e. what is the use case?</div><div><br class=""></div><div>As an aside, I am not formally proposing this. I am just discussing potential opportunities for optimization given that we would need (as apart of this proposal) to add knowledge of unicode to the compiler which would allow for compile time transformations.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 22, 2016 at 6:10 PM, Michael Gottesman <span dir="ltr" class=""><<a href="mailto:mgottesman@apple.com" target="_blank" class="">mgottesman@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
> On Sep 22, 2016, at 10:50 AM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
><br class="">
>> On Jul 26, 2016, at 12:26 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
>><br class="">
>> +1. Even if it's too late for Swift 3, though, I'd argue that it's highly unlikely to be code-breaking in practice. Any existing code that would get tripped up by this normalization is arguably broken already.<br class="">
><br class="">
> I'm inclined to agree. To be paranoid about perfect compatibility, we could conceivably allow existing code with differently-normalized identifiers with a warning based on Swift version, but it's probably not worth it. It'd be interesting to data-mine Github or the iOS Swift Playgrounds app and see if this breaks any Swift 3 code in practice.<br class="">
<br class="">
</span>As an additional interesting point here, we could in general normalize unicode strings. This could potentially reduce the size of unicode characters or allow us to constant propagate certain unicode algorithms in the optimizer.<br class="">
<br class="">
><br class="">
> -Joe<br class="">
<div class=""><div class="">> ______________________________<wbr class="">_________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class="">
</div></div></blockquote></div><br class=""></div></div>
</div></blockquote></span></div><br class=""></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>