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

[Zach Waldowski]

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[1] 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








Links:

  1. http://stackoverflow.com/a/27456220/251153
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170330/bebda404/attachment.html>