[swift-evolution] [Draft] Target-specific CChar
william at housedillon.com
Thu Mar 3 12:03:51 CST 2016
>> I propose that the CChar be aliased to UInt8 on targets where char is unsigned, and Int8 on platforms where char is signed.
> This will make Swift code _less_ portable, since you will have to write different Swift code depending on whether your C implementation of char is signed or unsigned.
I’m not sure I agree in general, but I can see why you think that way.
>> Alternatives considered
>> The only real alternative is the status quo.
> No it isn’t. As long as CChar remains an alias to one of the integer types, it would be better to make it an alias to UInt8. The reason being that char * is often a pointer to a sequence of UTF-8 bytes and this interpretation is only going to get more common. String.UTF8View consists of a sequence of CodeUnits and UTF8.CodeUnit is, itself an alias to UInt8.
> As others have said, it might be even better to have a new opaque type that’s 8 bits wide (I assume we are ignoring the fact that the C standard doesn’t define the width of a byte) but, in that case, I would argue that bitwise operations should be allowed on it.
I had a similar thought about bitwise operators. Please see the updated gist:
More information about the swift-evolution