[swift-evolution] [Pitch] String revision proposal #1

[Félix Cloutier]

Does it? According to the documentation for the current decodeCString <https://developer.apple.com/reference/swift/string/1641442-decodecstring>, it seems to accept an UnsafePointer, not a buffer pointer, and expects the string to be null-terminated. Am I missing another overload?

> Le 30 mars 2017 à 17:27, Zach Waldowski via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> On Thu, Mar 30, 2017, at 12:35 PM, Félix Cloutier via swift-evolution wrote:
>> I don't have much non-nitpick issues that I greatly care about; I'm in favor of this.
>> 
>> My only request: it's currently painful to create a String from a fixed-size C array. For instance, if I have a pointer to a `struct foo { char name[16]; }` in Swift where the last character doesn't have to be a NUL, it's hard to create a String from it. Real-world examples of this are Mach-O LC_SEGMENT and LC_SEGMENT_64 commands.
>> 
>> 
>> The generally-accepted wisdom <http://stackoverflow.com/a/27456220/251153> is that you take a pointer to the CChar tuple that represents the fixed-size array, but this still requires the string to be NUL-terminated. What do we think of an additional init(cString:) overload that takes an UnsafeBufferPointer and reads up to the first NUL or the end of the buffer, whichever comes first?
> 
> Today's String already supports this through `String.decodeCString(_:as:repairingInvalidCodeUnits:)`, passing a buffer pointer.
> 
> Best,
>   Zachary Waldowski
>   zach at waldowski.me <mailto:zach at waldowski.me>
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170330/b4c60680/attachment.html>