is there a roadmap for strings + unicode in swift 5? will unicode normalization and other functionality be available in the standard library?
https://docs.oracle.com/javase/8/docs/api/java/text/Normalizer.html https://www.unicode.org/reports/tr31/ http://www.unicode.org/reports/tr44/ http://www.unicode.org/reports/tr18/ -- C. Keith Ray Senior Software Engineer / Trainer / Agile Coach * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf > On Oct 28, 2017, at 10:48 AM, Michael Ilseman via swift-evolution > <[email protected]> wrote: > > We are definitely looking at it, soon. Right now (working on Swift 4.1), most > of the String focus is on ABI-critical concerns, but better String APIs and > programming models is a focus area for Swift 5. > > > >> On Oct 25, 2017, at 3:34 PM, Kelvin Ma via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> I don’t think anyone is really looking at that at the time but +1 to >> bringing NSString functionality to String. This is something that gets >> talked about a lot but no one has really sat down to outline what such an >> API would look like. >> >> On Wed, Oct 25, 2017 at 3:24 PM, David Hart via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> > On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution >> > <[email protected] <mailto:[email protected]>> wrote: >> > >> > >> > >> > Sent from my iPad >> > >> >> On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution >> >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> >> I think to maintain source compatibility, the old behavior would be >> >> preserved until/if we remove -swift-version 4 mode. By deprecating it >> >> though, we won’t have to devote as much time to maintaining it going >> >> forward. >> > >> > I think the point is that some of the APIs should continue to be offered, >> > but directly rather than via NSString. We need an analysis of what APIs >> > are affected that includes recommendations on which to deprecate and which >> > to replace. We can’t make an informed decision without that. >> >> This is also closely linked to the new String APIs which the String >> Manifesto touched upon but never got implemented. It’d be nice to know what >> plans the Standard Library team has in that regard for Swift 5. >> >> >> >> >> Slava >> >> >> >>> On Oct 24, 2017, at 3:54 PM, Philippe Hausler <[email protected] >> >>> <mailto:[email protected]>> wrote: >> >>> >> >>> I think any serious proposal with the removal of APIs would need to >> >>> consider source compatibility and to do so you should likely audit the >> >>> API surface area that is being offered (and replace it via the >> >>> NSStringAPI.swift extension) >> >>> >> >>>> On Oct 24, 2017, at 3:12 PM, Slava Pestov via swift-evolution >> >>>> <[email protected] <mailto:[email protected]>> wrote: >> >>>> >> >>>> Perhaps you could write up a proposal to outline the missing >> >>>> functionality :-) >> >>>> >> >>>> Slava >> >>>> >> >>>>> On Oct 24, 2017, at 3:09 PM, Jonathan Hull <[email protected] >> >>>>> <mailto:[email protected]>> wrote: >> >>>>> >> >>>>> I would feel better about it if String gained a lot of the utility of >> >>>>> NSString (so that we don’t have to go to NSString all the time for >> >>>>> methods) >> >>>>> >> >>>>> Thanks, >> >>>>> Jon >> >>>>> >> >>>>>> On Oct 24, 2017, at 3:00 PM, Slava Pestov via swift-evolution >> >>>>>> <[email protected] <mailto:[email protected]>> wrote: >> >>>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>> Members of NSString, except those defined in Foundation, are >> >>>>>> available on values of type String. For example, >> >>>>>> >> >>>>>> extension NSString { >> >>>>>> @objc func foo() {} >> >>>>>> } >> >>>>>> >> >>>>>> let s: String = “hello” >> >>>>>> >> >>>>>> s.foo() >> >>>>>> >> >>>>>> We don’t do this for any other bridged types, for instance NSArray >> >>>>>> methods are not imported as Array methods. It’s literally a special >> >>>>>> case in the type checker for member lookup on String. >> >>>>>> >> >>>>>> This behavior doesn’t really much sense conceptually and it was put >> >>>>>> in as a stop-gap in Swift 1 to beef up the String API. I would like >> >>>>>> to phase it out as follows: >> >>>>>> >> >>>>>> - Unconditional warning in Swift 4.1, with a fixit to insert an ‘as >> >>>>>> NSString’ cast >> >>>>>> - Error in Swift 5 with -swift-version 5 >> >>>>>> >> >>>>>> What does everyone think about this? >> >>>>>> >> >>>>>> Slava >> >>>>>> _______________________________________________ >> >>>>>> 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] <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] <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] <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] <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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > 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
