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]> 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] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
