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

Ben Rimmington me at benrimmington.com
Wed Jul 27 16:10:10 CDT 2016

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



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

No, CSignedChar and CUnsignedChar already exist:


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:


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

More information about the swift-evolution mailing list