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
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