Against deprecating aliases
Andrej Mitrovic
andrej.mitrovich at gmail.com
Wed Sep 28 12:43:13 PDT 2011
Another pull has been made right now which takes down more functions
and creates deprecated forwarding functions:
https://github.com/D-Programming-Language/phobos/pull/279
Honestly I don't understand the point of deprecating convenient
functions like that. It makes perfect sense to make a single toUTF(z)
template from an implementation point of view, but it doesn't make
sense to remove convenient toUTF8(z)/toUTF16(z) symbol names. Simple
aliases could be created that sit in Phobos.
Do the Phobos devs really expect people to use code like this:
CopyFileW(std.utf.toUTFz!(const(wchar)*)(from),
std.utf.toUTFz!(const(wchar)*)(to), false)
instead of this?:
CopyFileW(std.utf.toUTF16z(from), std.utf.toUTF16z(to), false)
I can understand that Mr. Verbosity likes to code like this, but I
certainly don't. Of course the answer to that is "write your own
aliases in your user code". Ok, but now I have to *manually* include
these aliases in all of my projects because I already rely on toUTF16z
being present:
public alias toUTFz!(const(wchar)*, string) toUTF16z;
public alias toUTFz!(const(wchar)*, wstring) toUTF16z;
public alias toUTFz!(const(wchar)*, dstring) toUTF16z;
Doing this in my projects and/or having to rewrite my build scripts is
a complete waste of my time. Deprecating convenient existing names
like toUTF16z, coupled with notices that don't even tell me which file
is importing the deprecated symbols is a cocktail of nonsense. Why
deprecate symbol names that users will inevitably introduce them in
their user-code again? The rule is: if it's widely used enough, it
should be in the standard library. An alias doesn't cost you a dime to
keep in the library.
Most of us D programmers work on *multiple* projects at once, and we
don't have any sophisticated tools like, say, Java devs do, so we have
to do almost everything manually when deprecation warnings kick in. I
really think we should keep aliases around which have an almost zero
maintenance cost in Phobos, while they have a huge cost for the
library *users* when they're removed.
I think we're only getting away with this because we have a small D
community. Take a look at QT, for example. They not only keep
source-level compatibility, but they also keep *binary-level*
compatibility between releases. OTOH we can't even have source-level
compatibility between releases..
TLDR: Don't make Phobos upgrades annoying.
More information about the Digitalmars-d
mailing list