[swift-evolution] [Pitch] Remove transparent bridging between Swift strings and char *
gwynne at darkrainfall.org
Wed Jun 22 16:38:01 CDT 2016
As I understand it, UTF-8 for POSIX APIs is always (usually?) valid on macOS, valid on Linux _IF_ your LANG etc. are set to C or en_US.UTF-8, and of questionable validity on Windows. Is the stdlib possibly converting to the "system encoding" underneath and possibly silently dropping characters it can’t translate when the encoding is not UTF-8? Whichever thing is actually happening, I definitely agree this needs to be documented. I also somewhat agree that forcing an explicit call to a cString accessor is not entirely unreasonable (though it does present a danger of allowing such pointers to escape calls to C APIs, normally you would never see the raw value and there’s no reason to think it remains valid outside the scope of the conversion). Interop with C should be easy, but it shouldn’t be so easy that you can ignore the way the APIs work - dealing in UnsafePointers means thinking hard about memory management, even more so in some ways when doing interop from Swift than in plain C.
That having been said, the encoding issue is the part that concerns me more than the rest, I have no strong opinion either way about changing how the automatic bridging happens. If the encoding semantics were documented (maybe even with examples showing how to do it manually if you need more control for special cases), I’d be satisfied with the status quo.
-- Gwynne Raskind
> On Jun 22, 2016, at 15:01, Kenny Leung via swift-evolution <swift-evolution at swift.org> wrote:
>> On Jun 22, 2016, at 12:37 PM, Ben Rimmington <me at benrimmington.com> wrote:
>> But the cString(using:) method is from Foundation, and using UTF-8 should always succeed in any case.
> I suppose you’re right about that, but now it brings up more confusion in my mind about what’s in Foundation and what’s in the standard library. So would there be extensions on String in (Swift) Foundation that implements cString(encoding:)? What decides what functions are in the standard library and what are in Foundation?
>> UTF-8 by default is probably correct for POSIX APIs, but maybe not for Windows APIs (if code pages are expected).
> I guess it all depends on what you think should be valid for C strings. Based on the documentation, I guess the core team thinks UTF-8 is valid.
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution