Rename std.string.toStringz?

[kenji hara]

2011/6/26 kenji hara <k.hara.pg at gmail.com>:
>> 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