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 < [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
