Pitch: Member lookup on String should not find members of NSString

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

2 Likes

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

+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 <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

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

Slava

···

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

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 :slight_smile:

Slava

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

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 <phausler@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 :slight_smile:

Slava

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

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.

···

Sent from my iPad

On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:

Slava

On Oct 24, 2017, at 3:54 PM, Philippe Hausler <phausler@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 :slight_smile:

Slava

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

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 <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.

Slava

On Oct 24, 2017, at 3:54 PM, Philippe Hausler <phausler@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 :slight_smile:

Slava

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

Sent from my iPad

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.

···

On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:

Slava

On Oct 24, 2017, at 3:54 PM, Philippe Hausler <phausler@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 :slight_smile:

Slava

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

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 30 Oct 2017, at 6:16 am, Ted Kremenek via swift-evolution <swift-evolution@swift.org> wrote:

On Oct 24, 2017, at 3:56 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.

Slava

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/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 <swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto: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 <phausler@apple.com <mailto:phausler@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 <mailto:swift-evolution@swift.org>> wrote:
>>>>
>>>> Perhaps you could write up a proposal to outline the missing functionality :slight_smile:
>>>>
>>>> Slava
>>>>
>>>>> On Oct 24, 2017, at 3:09 PM, Jonathan Hull <jhull@gbis.com <mailto:jhull@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 <mailto: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 <mailto:swift-evolution@swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

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

> On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto: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 <phausler@apple.com <mailto:phausler@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 <mailto:swift-evolution@swift.org>> wrote:
>>>>
>>>> Perhaps you could write up a proposal to outline the missing functionality :slight_smile:
>>>>
>>>> Slava
>>>>
>>>>> On Oct 24, 2017, at 3:09 PM, Jonathan Hull <jhull@gbis.com <mailto:jhull@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 <mailto: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 <mailto:swift-evolution@swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

If there’s something there that you want, please pitch it.

1 Like