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

[Rod Brown via swift-evolution]

> On 30 Oct 2017, at 6:16 am, Ted Kremenek via swift-evolution 
>  wrote:
> 
> A complementary tactic would be that migration tool support to Swift 5 would 
> insert the needed casts to NSString.  That way even if the magic lookup is 
> gone in Swift 5 the code could be automatically migrated and preserve the 
> same semantics.  If this came to a formal proposal I’d really like to see 
> something like that considered.

Agreed.

I think that a lot of the NSString APIs would be nice to bring over native to 
Swift, and for those that are not yet implemented (or won’t be for various 
reasons) this would be a reasonable solution.

> 
>> On Oct 24, 2017, at 3:56 PM, Slava Pestov via swift-evolution 
>>  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.
>> 
>> Slava
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted Kremenek via swift-evolution]

A complementary tactic would be that migration tool support to Swift 5 would 
insert the needed casts to NSString.  That way even if the magic lookup is gone 
in Swift 5 the code could be automatically migrated and preserve the same 
semantics.  If this came to a formal proposal I’d really like to see something 
like that considered.

> On Oct 24, 2017, at 3:56 PM, Slava Pestov via swift-evolution 
>  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.
> 
> Slava
> 
>> On Oct 24, 2017, at 3:54 PM, Philippe Hausler  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 
>>>  wrote:
>>> 
>>> Perhaps you could write up a proposal to outline the missing functionality 
>>> :-)
>>> 
>>> Slava
>>> 
 On Oct 24, 2017, at 3:09 PM, Jonathan Hull  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 
>  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

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

[C. Keith Ray via swift-evolution]

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 
>  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 
>> > 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 
>> > wrote:
>> 
>> > On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution 
>> > > wrote:
>> >
>> >
>> >
>> > Sent from my iPad
>> >
>> >> On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution 
>> >> > 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 > >>> > 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 
>>  > wrote:
>> 
>>  Perhaps you could write up a proposal to outline the missing 
>>  functionality :-)
>> 
>>  Slava
>> 
>> > On Oct 24, 2017, at 3:09 PM, Jonathan Hull > > > 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 
>> >> > 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 
>> >> 
>> >
>> 
>>  

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

[Michael Ilseman via swift-evolution]

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 
>  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 
> > wrote:
> 
> > On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution 
> > > wrote:
> >
> >
> >
> > Sent from my iPad
> >
> >> On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution 
> >> > 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  >>> > 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 
>  > wrote:
> 
>  Perhaps you could write up a proposal to outline the missing 
>  functionality :-)
> 
>  Slava
> 
> > On Oct 24, 2017, at 3:09 PM, Jonathan Hull  > > 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 
> >> > 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 
> > 

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

[Kelvin Ma via swift-evolution]

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

>
> > On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >
> > 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.
>
> 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 
> 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  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
>
> ___
> 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

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

[David Hart via swift-evolution]

> On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution 
>>  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  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 
  wrote:
 
 Perhaps you could write up a proposal to outline the missing functionality 
 :-)
 
 Slava
 
> On Oct 24, 2017, at 3:09 PM, Jonathan Hull  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 
>>  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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution 
>  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  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 
>>>  wrote:
>>> 
>>> Perhaps you could write up a proposal to outline the missing functionality 
>>> :-)
>>> 
>>> Slava
>>> 
 On Oct 24, 2017, at 3:09 PM, Jonathan Hull  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 
>  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

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

[Johannes Weiß via swift-evolution]

+1, it's currently really non-obvious where these automatic bridges are 
happening which keeps costing me time.

> On 24 Oct 2017, at 11:00 pm, Slava Pestov via swift-evolution 
>  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

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

[Slava Pestov via swift-evolution]

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  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 
>>  wrote:
>> 
>> Perhaps you could write up a proposal to outline the missing functionality 
>> :-)
>> 
>> Slava
>> 
>>> On Oct 24, 2017, at 3:09 PM, Jonathan Hull  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 
  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

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

[Philippe Hausler via swift-evolution]

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 
>  wrote:
> 
> Perhaps you could write up a proposal to outline the missing functionality :-)
> 
> Slava
> 
>> On Oct 24, 2017, at 3:09 PM, Jonathan Hull  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 
>>>  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

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

[Slava Pestov via swift-evolution]

Perhaps you could write up a proposal to outline the missing functionality :-)

Slava

> On Oct 24, 2017, at 3:09 PM, Jonathan Hull  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 
>>  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

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

[Jonathan Hull via swift-evolution]

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 
>  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] Pitch: Member lookup on String should not find members of NSString

[Slava Pestov via swift-evolution]

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