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

Zach Waldowski zach at waldowski.me
Thu Mar 30 19:27:32 CDT 2017

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.


  Zachary Waldowski

  zach at waldowski.me


  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>

More information about the swift-evolution mailing list