Against deprecating aliases

[Gor Gyolchanyan]

Why is it so important to allocate the new string every time?
The client code may ensure the allocation by slice-copying it or my
specifying a default-off boolean parameter.
let's move the implementation from toUTF* into std.conv.to and remove the toUTF.
to!wstring("hello, world").toStringz() looks much better, then
toUTFz!(const(wchar*))("hello, world").
This is more intuitive, requires smaller interface and looks better.

On Thu, Sep 29, 2011 at 1:56 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On Thursday, September 29, 2011 13:48:12 Gor Gyolchanyan wrote:
>> Why wont to!string(), to!wstring() and to!dstring() to the trick?
>> This is essentially toUTF8, toUTF16 and toUTF32.
>> And the toStringz can be templated to take any of string, wstring and
>> dstring. I don't see any problem here.
>> Just drop the whole thing.
>
> std.conv.to uses toUTF8, toUTF16, and toUTF32 (and soon toUTF instead)
> internally. Also, calling toUTF directly rather than using std.conv.to
> guarantees that a new string is allocated, whereas std.conv.to will avoid
> allocating if it can. I really don't think that having toUTF instead of
> toUTF8, toUTF16, and toUTF32 is going to cause much grief.
>
> The problem is toUTF16z. std.conv.to not currently use toUTFz at all (though
> it may in the future), so it's not really a consideration at this point. The
> issue is that toUTF16z is heavily used by anyone calling Windows API
> functions, and calling toUTFz!(const(wchar*))(str) is definitely uglier and
> more verbose than calling toUTF16z(str). So, there's a definite argument for
> keeping toUTF16z. There really isn't much argument in keeping toUTF8, toUTF16,
> and toUTF32. I doubt that they're used much anyway, since as you point out, in
> the common case, std.conv.to does the job just fine, and toUTF should be just
> fine for the relatively rare cases when it's needed.
>
> - Jonathan M Davis
>