Rename std.string.toStringz?

[Daniel Gibson]

Am 26.06.2011 00:15, schrieb kenji hara:
>> 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

Why? toStringz doesn't care at all about encodings, it just adds a '\0'
to the array and returns a pointer to that array..