On Thu, Sep 22, 2016 at 6:54 PM, Michael Gottesman <[email protected]> wrote:
> > On Sep 22, 2016, at 4:19 PM, Xiaodi Wu <[email protected]> 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 <[email protected]> > wrote: > >> >> > On Sep 22, 2016, at 10:50 AM, Joe Groff via swift-evolution < >> [email protected]> wrote: >> > >> > >> >> On Jul 26, 2016, at 12:26 PM, Xiaodi Wu via swift-evolution < >> [email protected]> 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 >> > [email protected] >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
