You mean values of type String? 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!
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