@swift-ci sync

@swift-ci create

It's not clear from the problem description what we're trying to accomplish (why pass a string literal to the cString initializer?).

But there's a known deficiency in StaticString that's probably the fundamental problem. There's currently no way to get a CString from a StaticString without calling strdup.

We should probably add a .cString property to StaticString to allow this.
The other possiblity would be to make UnsafePointer<Int8> ExpressibleByStringLiteral.

Let me explain what I am trying to do. I was reading this post from Helge Hesse:

http://www.alwaysrightinstitute.com/swift-cstr/

All I was trying to do was create an example where we have /no/ mallocs so I could respond to his post. First I thought part of the problem is that String's static cstring case wasn't recognizing that we had a static string or something like that. So first I tried:

  let f = "abcdef.yyy"

and discovered that if I used:

  f.withCString(...)

we performed a copy it looks like. So I tried to use the cString initializer hoping that I would hit a fast path in the code and was surprised that I couldn't pass a global string to that constructor.

I can see two issues with CString APIs: string literals, and null termination.

1. string literals

StaticString is the way to avoid heap allocation for literals. Unfortunately there's no way to get a CString out. We definitely want some solution to this. Probably one of:

• StaticString.cString property

• StaticCString type

• UnsafePointer<CChar> directly ExpressibleByStringLiteral

The answer we choose probably depends on the answer to the null termination problem. The nice thing is that, since StaticString is immutable, we don't need any closure-based withCString API.

2. null termination

It seems that, in addition to avoiding heap allocation for literals, the user wants to generally expose String guts to CString APIs without a copy. I don't know if this has been discussed before, but I see two possibilities.

• the user should only deal in UnsafePointer<CChar> (or StaticString once we fix that). If you want to use native Swift features, you'll get a copy each time you go back and forth and that's just expected.

• a String variant optimized for CString APIs that allows a null-terminated UTF-8 representation. withCString would still need to rebind memory to CChar, but that's "free".

+cc @belkadan, @milseman

init(cString:) is for starting with a C string and getting a String. That's a different request than "make a statically-allocated C string", but is actually still reasonable, since normally we allow passing a String as a pointer (including string literals). I'm a little curious why that doesn't compile.

As far as actually getting a compile-time-guaranteed statically-allocated C string, I do think improving StaticString is the way to go, but I forget if StaticString guarantees a UTF-8 representation. I think it does, though, and that's probably what we want for C strings in Swift. (At some point we might also want to improve static representation of non-UTF-8 data, for data that is mostly text but might have specific non-textual bytes interspersed. C allows this in plain string literals with \x, but Swift always names Unicode codepoints, which makes it impossible to specify single bytes with values greater than 0x7F.)

Other relevant things: we should be able to statically allocate buffers usable by String, and we should be able to optimize out string-literal-to-String-to-C-string conversions.

Exactly. And we should document this better and make it clear that this is the blessed way to accomplish this simple task. I completely forgot about StaticString.

@belkadan Swift UTF-8 strings are UInt8, CStrings are CChar. `cString` is overloaded to handle either one. String also implicitly casts to either. Trying to do two conversions in one expression is an ambiguity. It would be nice if the type checker just gave precedence to the UInt8 conversion.