On Thu, Sep 22, 2016 at 6:54 PM, Michael Gottesman <mgottes...@apple.com>
wrote:

>
> On Sep 22, 2016, at 4:19 PM, Xiaodi Wu <xiaodi...@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 <mgottes...@apple.com>
> wrote:
>
>>
>> > On Sep 22, 2016, at 10:50 AM, Joe Groff via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >
>> >> On Jul 26, 2016, at 12:26 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@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@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to