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