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.

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

Reply via email to