[swift-evolution] [Proposal] Normalize Unicode Identifiers
Xiaodi Wu
xiaodi.wu at gmail.com
Thu Sep 22 19:09:04 CDT 2016
On Thu, Sep 22, 2016 at 6:54 PM, Michael Gottesman <mgottesman at apple.com>
wrote:
>
> On Sep 22, 2016, at 4:19 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> You mean values of type String?
>
>
> I was speaking solely of constant strings.
>
> 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!
>
>
> Why.
>
For one, I don't want to pay the computational cost of normalization at
runtime unless necessary. For another, I expect to be able to round-trip
user input. Normalization is not lossless and cannot be reversed. Finally,
if I want to use normalization form D (NFD), your proposal would make it
impossible, because (IIUC) serial NFC + NFD normalization can produce
different output than NFD normalization alone.
On Thu, Sep 22, 2016 at 6:10 PM, Michael Gottesman <mgottesman at apple.com>
> wrote:
>
>>
>> > On Sep 22, 2016, at 10:50 AM, Joe Groff via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> >
>> >> On Jul 26, 2016, at 12:26 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >>
>> >> +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.
>> >
>> > 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.
>>
>> 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.
>>
>> >
>> > -Joe
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160922/89a71bf1/attachment.html>
More information about the swift-evolution
mailing list