That's not correct; it's only a UTF-16 code unit on Windows.

Neither of those types would be the right choice. One would expect CWideChar to map directly to wchar_t, such that a C function using wchar_t is directly interoperable with a Swift function using CWideChar (like how CInt and int are mapped today.)

Changing the definition of this type would most likely lead to binary compatibility problems on ABI-stable platforms (i.e. Darwin) so care would need to be taken. It might make more sense to deprecate CWideChar and replace it with e.g. typealias CWChar = wchar_t or equivalent.

I'm going to take this issue and use it to conditionally declare CWideChar as a 16-bit type on Windows, since its current declaration is incorrect there. Everywhere else (POSIX-like, at least) has standardized on 32-bit/UCS-4/UTF-32.