Against deprecating aliases

Jonathan M Davis jmdavisProg at gmx.com
Thu Sep 29 03:38:20 PDT 2011


On Thursday, September 29, 2011 14:22:44 Gor Gyolchanyan wrote:
> 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.

1. There are situations (especially when interacting with C) when you need to 
ensure that a new string is allocated. Assuming that the original string type 
is the same as the target type, then dup would be enough for that, but if you 
have to worry about the string type at all, then it's just cleaner to have 
toUTF deal with that than having to do all the static ifs and whatnot in your 
own code.

2. It would definitely be messier to move toUTF into the appropriate function 
in std.conv.to. Having it as a separate function is much cleaner, and if 
you're doing that, you might as well have it be in std.utf where it is. Then 
anyone who actually wants to guarantee that the string conversion that they're 
doing allocates a new string can easily use it.

3. toStringz specifically deals with string, not wstring, so your example makes 
no sense. toUTFz is the generic way to ensure that a string (whatever its 
type) is null-terminated and to get its pointer all in one go. toStringz uses 
it as does toUTF16z. It would be a net loss to get rid of it. Yes, in order 
for toUTFz to do what it does, you need a rather verbose template argument, 
but that's what it takes to do what it does generically. It _is_ a good 
argument for having separate functions for the common cases (toStringz and 
toUTF16z), but there's no reason to get rid of toUTFz.

- Jonathan M Davis


More information about the Digitalmars-d mailing list