2011/6/26 kenji hara <[email protected]>: >> 1. Keep toStringz as it is (as well as toUTF16z) and either consider stringz >> to be some sort of word unique to the D community or just admit that we're >> not >> going to camelcase it because it would break too much code to do so. > > ++vote, but not all. > > Currently, the return type of toStringz is "zero-termniated UTF-8", > not "C-string". > > The 'C-string' word has multiple meanings=encodings. ASCII, Latin-1, > EUC, Shift-JIS (in Japan), UTF-8 (Linux?), UTF-16 (in Windows) ... > It depends on context. > > But, maybe, many of ’C-string' equals to "zero-terminated UTF-8' or > "zero-terminated UTF-16". > Other encodings should be supported by another module (std.encoding? > Is it living?). > > My proposal: > 1. Add three aliased types. > alias immutable(char)* stringz; // useful in Linux > alias immutable(wchar)* wstringz; // useful in Windows > alias immutable(dchar)* dstringz; // > 2. Rename current toStringz to toUTF8z, and add deprecated aliasing > 'toStringz' to keep compatibility. > (Adding toUTF32z in std.string module will increase consistency. > Templated toUTFXXz family is more better.) > 3. std.conv.to support conversion from 'any string type' to > (|wd)stringz type (by using toUTFXXz family). > > The main point is we should make the aliased type names as 'De facto' > type names, like string, wstring, dstring. (Remember the three string > types are aliased type in fact.) > > We can treat the type name uint as 'unsigned int'. Because it is just > built-in type name! > > User defined type names shoude be camel cased usually in D. > Then, let's make them built-in! Therefore we can remove camel cased > names from our choices. > > I think this proposal is usefulness, keeping compatibility, and consistent. > > Kenji >
Furthermore, "to!stringz" has same charecter count with "to!(char*)", but it has more const-ness and similar to "to!string". Kenji
