[swift-evolution] [Draft] Target-specific CChar
william at housedillon.com
Fri Mar 4 18:02:34 CST 2016
I’ve been exploring the idea of importing C chars as RawByte (and type aliasing RawByte to CChar) in my prototype branch of Swift, and I would appreciate some insight from the hive mind. Specifically, I’m interested in opinions about where to “draw the line” regarding C strings.
Currently (in the master branch) it’s easy convert between NSString, String and C-strings (often represented somewhat inconsistently by [CChar] or [(U)Int8], or UnsafePointer<CChar>). If we are interested in importing C char as RawByte, we have to decide where C strings become UTF8 (i.e. UInt8). I feel most comfortable drawing this line as close to C as possible, but I could see that there would be a reason for leaving it as CChar until it becomes proper UTF8.
If every reference to “Cstring” (for example: public init?(CString: UnsafePointer<CChar>…) is done with CChar, there can be a clean break, and an obvious place where Swift’s String handling begins, and C string handling ends. It may discourage people from trying to do string processing outside of the context of unicode (kinda). It would still be possible for people to work with characters in a C-string, however, as CChar will have a small number of operators defined over it, and you could always cast it to UInt8 or Int8.
I hope that this email opens up the discussion, and we can come up with a good idea that works for most people. I’m kinda spinning because I don’t have a firm idea of the trade-offs for each solution. Any consensus here would certainly help me finish the prototype.
More information about the swift-evolution