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]> wrote: > > > On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution < > [email protected]> wrote: > > > > > > > > Sent from my iPad > > > >> On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution < > [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]> > 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]> 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]> 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]> 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] > >>>>>> 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 > > > > _______________________________________________ > > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
