[swift-evolution] Pitch: Member lookup on String should not find members of NSString

[Kelvin Ma]

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 <
swift-evolution at swift.org> wrote:

>
> > On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >
> > Sent from my iPad
> >
> >> On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution <
> swift-evolution at swift.org> 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 <phausler at apple.com>
> 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 <
> swift-evolution at swift.org> wrote:
> >>>>
> >>>> Perhaps you could write up a proposal to outline the missing
> functionality :-)
> >>>>
> >>>> Slava
> >>>>
> >>>>> On Oct 24, 2017, at 3:09 PM, Jonathan Hull <jhull at gbis.com> 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 <
> swift-evolution at swift.org> 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
> >>>>>> swift-evolution at swift.org
> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> swift-evolution mailing list
> >>>> swift-evolution at swift.org
> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>>
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171025/7abfe9c3/attachment.html>