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

[Ben Rimmington]

> On 27 Jul 2016, at 15:08, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> 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