Sent from my iPad
> On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution
> <swift-evolution@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.
>
> Slava
>
>> On Oct 24, 2017, at 3:54 PM, Philippe Hausler <phaus...@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@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 <jh...@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@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@swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
