Against deprecating aliases

[Jonathan M Davis]

On Wednesday, September 28, 2011 21:43:13 Andrej Mitrovic wrote:
> 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.

Having toUTF and toUTFz is a marked improvement in many cases - especially for 
generic code. They're being added regardless of what the deal with toUTF16z 
is.

The reason that toUTF16z is being removed is essentially because Andrei is 
very much opposed to having functions with specific types in their names and 
thinks that they should all be generic. Personally, I'm not opposed to keeping 
toUTF16z as an alias or wrapper to toUTFz. It's Andrei that seems to feel 
stongly about it. So, if enough people really want to keep toUTF16z, then I 
think that that can happen.

As for general compatability changes to Phobos, the idea at least is that we 
get all such changes out of the way (particularly major module redesigns) in 
the short term and then leave the APIs essentially stable in the long term. 
So, the number changes like this should be diminishing.

As for the deprecation message issues, that's being worked on but no decision 
has yet been made on how exactly we're going to improve deprecated to handle 
it.

- Jonathan M Davis