Against deprecating aliases

[Jonathan M Davis]

On Thursday, September 29, 2011 09:20:39 Christophe wrote:
> Jonathan M Davis , dans le message (digitalmars.D:145653), a écrit :
> > 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.
> 
> Sure, toWcharz would be a really bad name, but UTF16 is not a specific
> type, it is a specific encoding.

UTF-16 and wchar are synonymous. wchar is UTF-16 by definition. If you have 
toUTF8, toUTF16, and toUTF32, then it's a pain for generic code, because yo 
uhave to do a bunch of static ifs on the type that you're converting to and 
call the appropriate function, in spite of the fact that the type that you're 
converting to gives you exactly what the conversion should be. So, putting 
UTF16 in the name is tantemount to putting wchar it the name, it just makes 
way more sense to have toUTF and toUTFz. The issue here is that using toUTFz 
is more cumbersome, because it's more verbose, and there is one very common 
use case which toUTF16z fulfills. So there is a usability argument in favor of 
toUTF16z. In general however, putting UTF8, UTF16, or UTF32 in a function name 
is bad design, since it's essentially identical to putting char, wchar, and 
dchar in the function names, which just is not generic at all.

- Jonathan M Davis