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

[C. Keith Ray]

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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> > On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> >>>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> swift-evolution mailing list
>> >>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> >>>
>> >>
>> >> _______________________________________________
>> >> swift-evolution mailing list
>> >> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> >> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> >
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20171028/e32bfc1f/attachment.html>