[swift-evolution] [Draft] Target-specific CChar

[William Dillon]

>> 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:

https://gist.github.com/hpux735/eafad78108ed42879690

- Will