> On 27 Jul 2016, at 15:08, Xiaodi Wu <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
