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 <[email protected]> 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 >
