Why are deprecated aliases considered equal for resolution?

[Jonathan M Davis]

On Friday, May 11, 2018 14:02:22 Nicholas Wilson via Digitalmars-d-learn 
wrote:
> ---------
> module a;
>
> struct foo {}
>
> deprecated alias bar = foo;
>
> ----------
> module b;
> struct bar {};
>
>
> -----------
> module c;
>
> import a;
> import b;
>
> void baz(bar b) {}
>
> Error: `a.bar` at source/a.d(5,1) conflicts with `b.bar` at
> .b.d(2,1)
>
> I would have thought the undeprecated alias would have been used.

As I understand it, the only effect that deprecated really has is that you
get a message printed telling you that the symbol is deprecated if it's used
in undeprecated code. And that being the case, it definitely wouldn't affect
something like overload resolution.

And if you think about it, making deprecated affecting things like overload
resolution could get pretty risky. Remember that the whole idea here is that
a symbol is deprecated so that folks will stop using it, but you don't want
code to break because of it. If anything behaves differently, then it risks
code breakage, and that's exactly what you were trying to avoid by
deprecating the symbol rather than just removing it.

So, in general, when something is deprecated, we get to continue to live
with the negatives of having it around - it's just that it discourages its
use in new code and encourages people to stop using that symbol. So, when
the symbol is removed, the only code that breaks should be unmaintained code
that wasn't updated appropriately. But in the interim, it's still there
causing symbol conflicts and whatnot, and I don't see how it could be
otherwise without risking code breakage simply due to deprecation, and we
really don't want that. It's disruptive enough as it is just to tell folks
to stop using a symbol even if nothing breaks as long as the symbol is still
around.

- Jonathan M Davis