SE-163: String Revision: Collection Conformance, C Interop, Transcoding

Evolution Announcements
1

Hello, Swift community!

The review of "SE-163: String Revision: Collection Conformance, C Interop, Transcoding" begins now and runs through next Tuesday, April 11th. The proposal is available here:
  swift-evolution/0163-string-revision-1.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

  Proposal link: swift-evolution/0155-normalize-enum-case-representation.md at master · apple/swift-evolution · GitHub

  Reply text

  Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

John McCall
Review Manager

2

Hello, Swift community!

The review of "SE-163: String Revision: Collection Conformance, C Interop,
Transcoding" begins now and runs through next Tuesday, April 11th. The
proposal is available here:
GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0163-string-revision-1.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:

Proposal link: https://github.com/apple/swift-evolution/blob/
master/proposals/0155-normalize-enum-case-representation.md

Reply text

Other replies

*What goes into a review?*

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

• What is your evaluation of the proposal?

+1. This is a good start for the String overhaul.

• Is the problem being addressed significant enough to warrant a change to
Swift?

Yes.

• Does this proposal fit well with the feel and direction of Swift?

Yes.

I continue to want to nitpick the nouning of the verb "parse." I can agree
that it's not a "ParsedResult" because not all instances will have a
result. But it certainly is a "ParsingResult" and not a "ParseResult"
because parse really isn't a noun. That is all.

(Personally, I would be happy with either "StringProtocol" or "Unicode." If
the Collection-ness of the protocol is important, "UnicodeCollection" might
allay some people's fears that "Unicode" is a funny-sounding protocol name.)

• If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?

I absolutely love that Swift is Unicode-correct by default. In this
respect, Swift is already ahead of other languages. The lack of Collection
conformance is a pain point, and this proposal addresses that head-on.

• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

A moderate amount of effort; previously, a greater amount of effort.
Also, clearly more effort than the review manager, since the last link is
copypasta ;)

More information about the Swift evolution process is available at

···

On Wed, Apr 5, 2017 at 1:39 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote:

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

John McCall
Review Manager

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

3

During the proposal phase, we asked how this would handle fixed-length strings with an optional NUL terminator. For instance, in a C `struct Foo { char name[8]; };`, `name` stops at the first \0, or at the eighth byte, whichever comes first. IIRC, Ben said that it would be handled, but I'd like to have it clarified.

Is it correct to assume that a UnicodeEncoding is expected to return UnicodeParseResult.emptyInput when it sees a NUL character (thus stopping before the end of the buffer if necessary)? Is it also correct to assume that if you need this functionality, you'll be looking at code like this?

var result = ""
UnicodeEncoding.parseForward(bufferPointer) { result += $0 }

···

Le 5 avr. 2017 à 11:39, John McCall via swift-evolution <swift-evolution@swift.org> a écrit :

Hello, Swift community!

The review of "SE-163: String Revision: Collection Conformance, C Interop, Transcoding" begins now and runs through next Tuesday, April 11th. The proposal is available here:
  https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

  Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md

  Reply text

  Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

John McCall
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

+1. This is well thought out and an important evolution of string.

Hello, Swift community!

The review of "SE-163: String Revision: Collection Conformance, C Interop, Transcoding" begins now and runs through next Tuesday, April 11th. The proposal is available here:
  https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?

+1

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes

  • Does this proposal fit well with the feel and direction of Swift?

Yes

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Swift is ahead of most other languages in sweeping unicode support, and this refines swift’s position.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Multiple readings, but not in-depth study.

···

On Apr 5, 2017, at 11:39 AM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

5

review of "SE-163: String Revision: Collection Conformance, C Interop,
Transcoding"

What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to
Swift?

Yes. It is much more consistent to think of a String as a Collection of
Characters and change to copying when taking a sub-string is welcome.

• Does this proposal fit well with the feel and direction of Swift?

Yes. It will make String code easier to follow.

• If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

Yes Java. Change to copying sub-strings worked well.

• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Read the proposal and familiar with similar issues in Java

  -- Howard.

···

On 6 April 2017 at 04:39, John McCall <rjmccall@apple.com> wrote:

Hello, Swift community!

The review of "SE-163: String Revision: Collection Conformance, C Interop,
Transcoding" begins now and runs through next Tuesday, April 11th. The
proposal is available here:
GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0163-string-revision-1.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:

Proposal link: https://github.com/apple/swift-evolution/blob/
master/proposals/0155-normalize-enum-case-representation.md

Reply text

Other replies

*What goes into a review?*

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to
Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

More information about the Swift evolution process is available at
https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

John McCall
Review Manager

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

6

Hello, Swift community!

The review of "SE-163: String Revision: Collection Conformance, C Interop, Transcoding" begins now and runs through next Tuesday, April 11th. The proposal is available here:
  https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md
  • What is your evaluation of the proposal?

+1, looks great

  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?

yes to both

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I’ve yet to use a language with Swift’s unicode capabilities, but I might compare to Ruby 1.9+ strings, which support all encodings with one type. In comparison, I greatly prefer the “forcing” of the unicode and extended grapheme clusters mental model, rather than presenting a developer with sets of both array-of-characters and array-of-bytes semantics at once

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading of proposal as well as reading of the String manifesto before.

-DW

···

On Apr 5, 2017, at 12:39 PM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

7

Hello, Swift community!

The review of "SE-163: String Revision: Collection Conformance, C Interop, Transcoding" begins now and runs through next Tuesday, April 11th. The proposal is available here:
  https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

  Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md

  Reply text

  Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?

+1. (If I could +100, I would). Great start to the string overhaul.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Aligns the string model much closer to the mental model we manipulate strings with.

  • Does this proposal fit well with the feel and direction of Swift?

Yes. Its a tidier and more consistent implementation of what ultimately ends up being a convoluted collection of characters.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Some experience with C++ and lots of experience with Swift 1, 2 and Obj-C Strings. This brings Swift String back to the consistent logical clarity it had in Swift 1.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading, following Swift String discussions, etc.

···

On 6 Apr 2017, at 4:39 am, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

John McCall
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

8

Hello, Swift community!

The review of "SE-163: String Revision: Collection Conformance, C Interop, Transcoding" begins now and runs through next Tuesday, April 11th. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md

Reply text

Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

• What is your evaluation of the proposal?

Looks great! Removing collection conformance from String made sense to me initially, but in practice is just an arbitrary barrier. It is just too common that you need to treat a string like a collection.

• Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

• Does this proposal fit well with the feel and direction of Swift?

Absolutely. I love that substring behavior is becoming more obvious. Before the Strings manifesto I had no idea that substrings referenced the original string. For many operations, a substring will be consumed and then discarded, so non copying is what you want. Other times, you are discarding the original and keeping the copy, in which case the language pushes you towards creating a copy, even if the programmer isn’t aware of what they are doing (I’ve seen this with collections). And, very occasionally, it makes sense to keep the subcollection around if you are also referencing the original.

This design has been proven to me to be the best of all worlds with collections.

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

a quick reading

More information about the Swift evolution process is available at https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

John McCall
Review Manager

David Beck
davidb@acst.com

9

During the proposal phase, we asked how this would handle fixed-length strings with an optional NUL terminator. For instance, in a C `struct Foo { char name[8]; };`, `name` stops at the first \0, or at the eighth byte, whichever comes first. IIRC, Ben said that it would be handled, but I'd like to have it clarified.

Is it correct to assume that a UnicodeEncoding is expected to return UnicodeParseResult.emptyInput when it sees a NUL character (thus stopping before the end of the buffer if necessary)? Is it also correct to assume that if you need this functionality, you'll be looking at code like this?

var result = ""
UnicodeEncoding.parseForward(bufferPointer) { result += $0 }

Hi Félix,

Having talked about it among the team, it feels like we should add an initializer from a Collection of code units to this proposal. Therefore given a pointer p to some utf8 and a length n, you would write:

let b = UnsafeBuffer(start: p, count: n)
// naming opinions on the argument labels welcomed, this is probably what I’d go for...
let s = String(b, fromEncoding: UTF8.self)

Similar to the C string inits, this would only be a repairing initializer.

Your request goes a little bit further though. For that, I would say that it probably doesn’t deserve a special dedicated initializer. You could instead search for the nil using index(of:):

let i = b.index(of: 0)
let s = String(b[..<i], UTF8.self) // one-sided ranges pitch forthcoming ;)

Does this sound reasonable?

···

On Apr 5, 2017, at 10:32 PM, Félix Cloutier <felixcca@yahoo.ca> wrote:

Le 5 avr. 2017 à 11:39, John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Hello, Swift community!

The review of "SE-163: String Revision: Collection Conformance, C Interop, Transcoding" begins now and runs through next Tuesday, April 11th. The proposal is available here:
  https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

  Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md

  Reply text

  Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

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

10

It probably depends on the positioning of the initializer. I strongly associate the collection initializer to the special case of UnsafeBufferPointer<CChar>, and the result strings will probably be passed back to C at some point, where an embedded NUL terminates the string (inconsistently with what Swift does). As a Swift-first feature, parsing the whole buffer regardless of embedded NULs makes sense, but as an interop feature, that's almost certainly not what developers will be looking for.

That probably passes the bar of being reasonable, though. I'd advise documenting that it doesn't stop on NUL characters.

Félix

···

Le 6 avr. 2017 à 17:34, Ben Cohen <ben_cohen@apple.com> a écrit :

On Apr 5, 2017, at 10:32 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@yahoo.ca>> wrote:

During the proposal phase, we asked how this would handle fixed-length strings with an optional NUL terminator. For instance, in a C `struct Foo { char name[8]; };`, `name` stops at the first \0, or at the eighth byte, whichever comes first. IIRC, Ben said that it would be handled, but I'd like to have it clarified.

Is it correct to assume that a UnicodeEncoding is expected to return UnicodeParseResult.emptyInput when it sees a NUL character (thus stopping before the end of the buffer if necessary)? Is it also correct to assume that if you need this functionality, you'll be looking at code like this?

var result = ""
UnicodeEncoding.parseForward(bufferPointer) { result += $0 }

Hi Félix,

Having talked about it among the team, it feels like we should add an initializer from a Collection of code units to this proposal. Therefore given a pointer p to some utf8 and a length n, you would write:

let b = UnsafeBuffer(start: p, count: n)
// naming opinions on the argument labels welcomed, this is probably what I’d go for...
let s = String(b, fromEncoding: UTF8.self)

Similar to the C string inits, this would only be a repairing initializer.

Your request goes a little bit further though. For that, I would say that it probably doesn’t deserve a special dedicated initializer. You could instead search for the nil using index(of:):

let i = b.index(of: 0)
let s = String(b[..<i], UTF8.self) // one-sided ranges pitch forthcoming ;)

Does this sound reasonable?

Le 5 avr. 2017 à 11:39, John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Hello, Swift community!

The review of "SE-163: String Revision: Collection Conformance, C Interop, Transcoding" begins now and runs through next Tuesday, April 11th. The proposal is available here:
  https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

  Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md

  Reply text

  Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

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

11

+1 with this clarification / revision

···

On Apr 6, 2017, at 5:34 PM, Ben Cohen via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 5, 2017, at 10:32 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@yahoo.ca>> wrote:

During the proposal phase, we asked how this would handle fixed-length strings with an optional NUL terminator. For instance, in a C `struct Foo { char name[8]; };`, `name` stops at the first \0, or at the eighth byte, whichever comes first. IIRC, Ben said that it would be handled, but I'd like to have it clarified.

Is it correct to assume that a UnicodeEncoding is expected to return UnicodeParseResult.emptyInput when it sees a NUL character (thus stopping before the end of the buffer if necessary)? Is it also correct to assume that if you need this functionality, you'll be looking at code like this?

var result = ""
UnicodeEncoding.parseForward(bufferPointer) { result += $0 }

Hi Félix,

Having talked about it among the team, it feels like we should add an initializer from a Collection of code units to this proposal. Therefore given a pointer p to some utf8 and a length n, you would write:

let b = UnsafeBuffer(start: p, count: n)
// naming opinions on the argument labels welcomed, this is probably what I’d go for...
let s = String(b, fromEncoding: UTF8.self)

Similar to the C string inits, this would only be a repairing initializer.

Your request goes a little bit further though. For that, I would say that it probably doesn’t deserve a special dedicated initializer. You could instead search for the nil using index(of:):

let i = b.index(of: 0)
let s = String(b[..<i], UTF8.self) // one-sided ranges pitch forthcoming ;)

Does this sound reasonable?

Le 5 avr. 2017 à 11:39, John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Hello, Swift community!

The review of "SE-163: String Revision: Collection Conformance, C Interop, Transcoding" begins now and runs through next Tuesday, April 11th. The proposal is available here:
  https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

  Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md

  Reply text

  Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

John McCall
Review Manager
_______________________________________________
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