[SHORT Review] SE-0134: Rename two UTF8-related properties on String

Chris_Lattner · July 25, 2016, 6:18am

Hello Swift community,

The review of "SE-0134: Rename two UTF8-related properties on String" begins now and runs through July 26. Apologies for the short review cycle, but we’re right up against the end of source breaking changes for Swift 3. The proposal is available here:

swift-evolution/0134-rename-string-properties.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.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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,

-Chris Lattner
Review Manager

masters3d · July 25, 2016, 2:35pm

Hello Swift community,

The review of "SE-0134: Rename two UTF8-related properties on String" begins now and runs through July 26. Apologies for the short review cycle, but we’re right up against the end of source breaking changes for Swift 3. The proposal is available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.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.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read thread.

···

On Jul 24, 2016, at 11:18 PM, Chris Lattner 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,

-Chris Lattner
Review Manager

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

Charlie_Monroe1 · July 25, 2016, 7:35am

+1. Seems logical.

···

On Jul 25, 2016, at 8:18 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0134: Rename two UTF8-related properties on String" begins now and runs through July 26. Apologies for the short review cycle, but we’re right up against the end of source breaking changes for Swift 3. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.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.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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,

-Chris Lattner
Review Manager

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

David_Ronnqvist · July 25, 2016, 11:40am

+1. A small but good improvement.

It makes even more sense since the documentation for these calls it “null-terminated” (was called “nul-terminated” in the 2.2 documentation).

- David

···

On 25 Jul 2016, at 08:18, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0134: Rename two UTF8-related properties on String" begins now and runs through July 26. Apologies for the short review cycle, but we’re right up against the end of source breaking changes for Swift 3. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.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.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to 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,

-Chris Lattner
Review Manager

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

benrimmington · July 25, 2016, 2:27pm

<https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.md>

My suggestion for SE-0134 is to use the `utf8CString` name, overloading for CSignedChar and CUnsignedChar:

<https://github.com/apple/swift/blob/master/stdlib/public/core/CString.swift>

  extension String {
  - init(cString: UnsafePointer<CChar>)
  - init(cString: UnsafePointer<UInt8>)
  - init?(validatingUTF8 cString: UnsafePointer<CChar>)

  + init(utf8CString: UnsafePointer<CSignedChar>)
  + init(utf8CString: UnsafePointer<CUnsignedChar>)
  + init?(validatingUTF8CString: UnsafePointer<CSignedChar>)
  + init?(validatingUTF8CString: UnsafePointer<CUnsignedChar>)
  }

The properties would change to methods, overloaded by return type:

<https://github.com/apple/swift/blob/master/stdlib/public/core/StringUTF8.swift>

  extension String {
  - var nulTerminatedUTF8CString: ContiguousArray<CChar>
  - var nulTerminatedUTF8: ContiguousArray<UTF8.CodeUnit>

  + func utf8CString() -> ContiguousArray<CSignedChar>
  + func utf8CString() -> ContiguousArray<CUnsignedChar>
  }

## NOTES ##

UTF8.CodeUnit is defined as UInt8, and CChar is currently defined as Int8:

<https://github.com/apple/swift/blob/master/stdlib/public/core/CTypes.swift>

  /// The C 'char' type.
  ///
  /// This will be the same as either `CSignedChar` (in the common
  /// case) or `CUnsignedChar`, depending on the platform.
  public typealias CChar = Int8

/// The C 'signed char' type.
public typealias CSignedChar = Int8

/// The C 'unsigned char' type.
public typealias CUnsignedChar = UInt8

There's an abandoned proposal to update CChar:

<http://thread.gmane.org/gmane.comp.lang.swift.evolution/7925/focus=8158>

<http://thread.gmane.org/gmane.comp.lang.swift.evolution/8419>

String.init(cString: UnsafePointer<UInt8>) and nulTerminatedUTF8CString were added by SE-0107:

<swift-evolution/0107-unsaferawpointer.md at master · apple/swift-evolution · GitHub;

<https://github.com/apple/swift/commit/c7aa8284c905a73959ad69255cb56c38db80d039>

Foundation.NSString uses the `utf8String` name instead:

<https://developer.apple.com/reference/foundation/nsstring/1412128-init>

<https://developer.apple.com/reference/foundation/nsstring/1411189-utf8string>

-- Ben

benrimmington · July 27, 2016, 12:33pm

<https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.md>

There's another method for SE-0134 which could be renamed or removed:

<https://github.com/apple/swift/blob/master/stdlib/public/core/LifetimeManager.swift>

  extension String {
  - func withCString<Result>(
  - _ body: @noescape (UnsafePointer<Int8>) throws -> Result
  - ) rethrows -> Result

  + func withUTF8CString<Result>(
  + _ body: @noescape (UnsafePointer<CSignedChar>) throws -> Result
  + ) rethrows -> Result

  + func withUTF8CString<Result>(
  + _ body: @noescape (UnsafePointer<CUnsignedChar>) throws -> Result
  + ) rethrows -> Result
  }

The overloads (CSignedChar and CUnsignedChar) are needed if CChar will become UInt8 on some platforms.

-- Ben

···

On 25 Jul 2016, at 15:27, Ben Rimmington wrote:

<https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.md>

My suggestion for SE-0134 is to use the `utf8CString` name, overloading for CSignedChar and CUnsignedChar:

  <https://github.com/apple/swift/blob/master/stdlib/public/core/CString.swift>

  extension String {
  - init(cString: UnsafePointer<CChar>)
  - init(cString: UnsafePointer<UInt8>)
  - init?(validatingUTF8 cString: UnsafePointer<CChar>)

  + init(utf8CString: UnsafePointer<CSignedChar>)
  + init(utf8CString: UnsafePointer<CUnsignedChar>)
  + init?(validatingUTF8CString: UnsafePointer<CSignedChar>)
  + init?(validatingUTF8CString: UnsafePointer<CUnsignedChar>)
  }

The properties would change to methods, overloaded by return type:

  <https://github.com/apple/swift/blob/master/stdlib/public/core/StringUTF8.swift>

  extension String {
  - var nulTerminatedUTF8CString: ContiguousArray<CChar>
  - var nulTerminatedUTF8: ContiguousArray<UTF8.CodeUnit>

  + func utf8CString() -> ContiguousArray<CSignedChar>
  + func utf8CString() -> ContiguousArray<CUnsignedChar>
  }

## NOTES ##

UTF8.CodeUnit is defined as UInt8, and CChar is currently defined as Int8:

  <https://github.com/apple/swift/blob/master/stdlib/public/core/CTypes.swift>

  /// The C 'char' type.
  ///
  /// This will be the same as either `CSignedChar` (in the common
  /// case) or `CUnsignedChar`, depending on the platform.
  public typealias CChar = Int8

  /// The C 'signed char' type.
  public typealias CSignedChar = Int8

  /// The C 'unsigned char' type.
  public typealias CUnsignedChar = UInt8

There's an abandoned proposal to update CChar:

  <http://thread.gmane.org/gmane.comp.lang.swift.evolution/7925/focus=8158>

  <http://thread.gmane.org/gmane.comp.lang.swift.evolution/8419>

String.init(cString: UnsafePointer<UInt8>) and nulTerminatedUTF8CString were added by SE-0107:

  <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#cstring-conversion>

  <https://github.com/apple/swift/commit/c7aa8284c905a73959ad69255cb56c38db80d039>

Foundation.NSString uses the `utf8String` name instead:

  <https://developer.apple.com/reference/foundation/nsstring/1412128-init>

  <https://developer.apple.com/reference/foundation/nsstring/1411189-utf8string>

xwu · July 27, 2016, 2:08pm

Ben, while I'm broadly sympathetic to making CChar work more widely, if I
recall correctly this was a rather complex discussion topic you're raising
again. Besides the unprecedented name (Unsigned is never spelled out at the
moment), I wonder if all the other salient issues involved are best left
for a wider discussion than is possible here, especially since the pitch
and proposal have been limited to two properties.

···

On Wed, Jul 27, 2016 at 07:33 Ben Rimmington via swift-evolution < swift-evolution@swift.org> wrote:

> On 25 Jul 2016, at 15:27, Ben Rimmington wrote:
>
> <
https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.md
>
>
> My suggestion for SE-0134 is to use the `utf8CString` name, overloading
for CSignedChar and CUnsignedChar:
>
> <
https://github.com/apple/swift/blob/master/stdlib/public/core/CString.swift
>
>
> extension String {
> - init(cString: UnsafePointer<CChar>)
> - init(cString: UnsafePointer<UInt8>)
> - init?(validatingUTF8 cString: UnsafePointer<CChar>)
>
> + init(utf8CString: UnsafePointer<CSignedChar>)
> + init(utf8CString: UnsafePointer<CUnsignedChar>)
> + init?(validatingUTF8CString: UnsafePointer<CSignedChar>)
> + init?(validatingUTF8CString: UnsafePointer<CUnsignedChar>)
> }
>
> The properties would change to methods, overloaded by return type:
>
> <
https://github.com/apple/swift/blob/master/stdlib/public/core/StringUTF8.swift
>
>
> extension String {
> - var nulTerminatedUTF8CString: ContiguousArray<CChar>
> - var nulTerminatedUTF8: ContiguousArray<UTF8.CodeUnit>
>
> + func utf8CString() -> ContiguousArray<CSignedChar>
> + func utf8CString() -> ContiguousArray<CUnsignedChar>
> }
>
> ## NOTES ##
>
> UTF8.CodeUnit is defined as UInt8, and CChar is currently defined as
Int8:
>
> <
https://github.com/apple/swift/blob/master/stdlib/public/core/CTypes.swift
>
>
> /// The C 'char' type.
> ///
> /// This will be the same as either `CSignedChar` (in the common
> /// case) or `CUnsignedChar`, depending on the platform.
> public typealias CChar = Int8
>
> /// The C 'signed char' type.
> public typealias CSignedChar = Int8
>
> /// The C 'unsigned char' type.
> public typealias CUnsignedChar = UInt8
>
> There's an abandoned proposal to update CChar:
>
> <
http://thread.gmane.org/gmane.comp.lang.swift.evolution/7925/focus=8158>
>
> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/8419>
>
> String.init(cString: UnsafePointer<UInt8>) and nulTerminatedUTF8CString
were added by SE-0107:
>
> <
https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#cstring-conversion
>
>
> <
Add basic CString <-> UTF8 API variants. · apple/swift@c7aa828 · GitHub
>
>
> Foundation.NSString uses the `utf8String` name instead:
>
> <
https://developer.apple.com/reference/foundation/nsstring/1412128-init>
>
> <
utf8String | Apple Developer Documentation
>

<
https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.md
>

There's another method for SE-0134 which could be renamed or removed:

        <
https://github.com/apple/swift/blob/master/stdlib/public/core/LifetimeManager.swift
>

        extension String {
        - func withCString<Result>(
        - _ body: @noescape (UnsafePointer<Int8>) throws -> Result
        - ) rethrows -> Result

        + func withUTF8CString<Result>(
        + _ body: @noescape (UnsafePointer<CSignedChar>) throws -> Result
        + ) rethrows -> Result

        + func withUTF8CString<Result>(
        + _ body: @noescape (UnsafePointer<CUnsignedChar>) throws ->
Result
        + ) rethrows -> Result
        }

The overloads (CSignedChar and CUnsignedChar) are needed if CChar will
become UInt8 on some platforms.

-- Ben

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

Felix_Cloutier1 · July 27, 2016, 4:06pm

I'm +1 on the proposal.

Félix

···

Le 27 juil. 2016 à 07:08:44, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> a écrit :

Ben, while I'm broadly sympathetic to making CChar work more widely, if I recall correctly this was a rather complex discussion topic you're raising again. Besides the unprecedented name (Unsigned is never spelled out at the moment), I wonder if all the other salient issues involved are best left for a wider discussion than is possible here, especially since the pitch and proposal have been limited to two properties.
On Wed, Jul 27, 2016 at 07:33 Ben Rimmington via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

> On 25 Jul 2016, at 15:27, Ben Rimmington wrote:
>
> <https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.md>
>
> My suggestion for SE-0134 is to use the `utf8CString` name, overloading for CSignedChar and CUnsignedChar:
>
> <https://github.com/apple/swift/blob/master/stdlib/public/core/CString.swift>
>
> extension String {
> - init(cString: UnsafePointer<CChar>)
> - init(cString: UnsafePointer<UInt8>)
> - init?(validatingUTF8 cString: UnsafePointer<CChar>)
>
> + init(utf8CString: UnsafePointer<CSignedChar>)
> + init(utf8CString: UnsafePointer<CUnsignedChar>)
> + init?(validatingUTF8CString: UnsafePointer<CSignedChar>)
> + init?(validatingUTF8CString: UnsafePointer<CUnsignedChar>)
> }
>
> The properties would change to methods, overloaded by return type:
>
> <https://github.com/apple/swift/blob/master/stdlib/public/core/StringUTF8.swift>
>
> extension String {
> - var nulTerminatedUTF8CString: ContiguousArray<CChar>
> - var nulTerminatedUTF8: ContiguousArray<UTF8.CodeUnit>
>
> + func utf8CString() -> ContiguousArray<CSignedChar>
> + func utf8CString() -> ContiguousArray<CUnsignedChar>
> }
>
> ## NOTES ##
>
> UTF8.CodeUnit is defined as UInt8, and CChar is currently defined as Int8:
>
> <https://github.com/apple/swift/blob/master/stdlib/public/core/CTypes.swift>
>
> /// The C 'char' type.
> ///
> /// This will be the same as either `CSignedChar` (in the common
> /// case) or `CUnsignedChar`, depending on the platform.
> public typealias CChar = Int8
>
> /// The C 'signed char' type.
> public typealias CSignedChar = Int8
>
> /// The C 'unsigned char' type.
> public typealias CUnsignedChar = UInt8
>
> There's an abandoned proposal to update CChar:
>
> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/7925/focus=8158>
>
> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/8419>
>
> String.init(cString: UnsafePointer<UInt8>) and nulTerminatedUTF8CString were added by SE-0107:
>
> <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#cstring-conversion>
>
> <https://github.com/apple/swift/commit/c7aa8284c905a73959ad69255cb56c38db80d039>
>
> Foundation.NSString uses the `utf8String` name instead:
>
> <https://developer.apple.com/reference/foundation/nsstring/1412128-init>
>
> <https://developer.apple.com/reference/foundation/nsstring/1411189-utf8string>

<https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.md>

There's another method for SE-0134 which could be renamed or removed:

        <https://github.com/apple/swift/blob/master/stdlib/public/core/LifetimeManager.swift>

        extension String {
        - func withCString<Result>(
        - _ body: @noescape (UnsafePointer<Int8>) throws -> Result
        - ) rethrows -> Result

        + func withUTF8CString<Result>(
        + _ body: @noescape (UnsafePointer<CSignedChar>) throws -> Result
        + ) rethrows -> Result

        + func withUTF8CString<Result>(
        + _ body: @noescape (UnsafePointer<CUnsignedChar>) throws -> Result
        + ) rethrows -> Result
        }

The overloads (CSignedChar and CUnsignedChar) are needed if CChar will become UInt8 on some platforms.

-- Ben

_______________________________________________
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

benrimmington · July 27, 2016, 9:10pm

Ben, while I'm broadly sympathetic to making CChar work more widely, if I recall correctly this was a rather complex discussion topic you're raising again.

Yes, I linked to the previous threads:

<http://thread.gmane.org/gmane.comp.lang.swift.evolution/7925/focus=8158>

<http://thread.gmane.org/gmane.comp.lang.swift.evolution/8419>

Besides the unprecedented name (Unsigned is never spelled out at the moment),

No, CSignedChar and CUnsignedChar already exist:

<https://github.com/apple/swift/blob/master/stdlib/public/core/CTypes.swift>

The equivalent Int8 and UInt8 could be used instead.

I wonder if all the other salient issues involved are best left for a wider discussion than is possible here, especially since the pitch and proposal have been limited to two properties.

Yes, the core team will probably merge <https://github.com/apple/swift/pull/3742> without ammendment.

But the fundamental issue is that UTF-8 characters can be treated as signed or unsigned:

<https://github.com/apple/swift/commit/c7aa8284c905a73959ad69255cb56c38db80d039>

The utf8CString() methods -- overloaded by return type -- could be useful when writing cross-platform code.

I also suggested the other changes for two reasons:

1. Foundation.NSString has many deprecated `cString` APIs, because it wasn't clear whether they used the UTF-8 or Mac OS Roman encoding?

2. If the CChar typealias will be defined as UInt8 on some platforms, the initializers will conflict:

  extension String {
    init(cString: UnsafePointer<CChar>) // Added by SE-0006.
    init(cString: UnsafePointer<UInt8>) // Added by SE-0107.
  }

-- Ben

···

On 27 Jul 2016, at 15:08, Xiaodi Wu <xiaodi.wu@gmail.com> wrote: