deprecate deprecated?

[Jonathan M Davis]

On Wednesday, November 07, 2012 08:03:54 monarch_dodra wrote:
> On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote:
> > I know there's been some long term unhappiness about the
> > deprecated attribute - it's all-or-nothing approach, poor
> > messages, etc. Each change in it changes the language and the
> > compiler.
> 
> I *just* had a conversation about this, but there *needs* to be a
> way to to tell the compiler: "don't use deprecated stuff": If it
> merely issues a warning, then you'll end up calling deprecated
> code, because traits will answer positively to something that is
> actually deprecated:
> 
> For example if a range has "deprecated opIndex", and you try a
> search on that range, the implementation will take the RA road...
> 
> I had proposed a "three state -d":
> -- : Deprecated stuff just can't be used
> -d : You can use deprecated stuff, but you get no warning
> -dw : You can use deprecated stuff, and are served with a warning

It would be better if deprecated stuff warned by default and only errored if 
you ask it to. The problem is that as it is now, if you mark anything is 
deprecated, you instantly break all code using it without warning. The only 
way that anyone can know if you intended for something to be deprecated and 
get the chance to fix their code before it breaks is if you tell them in the 
documenation or changelog or whatnot, which doesn't tell them where in their 
code they're using it, and is frequently going to be outright ignored.

Certainly, from Phobos' perspective, the fact that deprecating something makes 
it so that it doesn't compile is a problem, because it means that as soon as 
we deprecate something, we break people's code (essentially without warning), 
and we don't want to do that. So, if we refuse to ever break people's code 
like that, we can't use deprecated.

It would be nice to have a two-tiered approach where something is soft 
deprecated (and therefore warns) or is hard deprecated (and therefore gives an 
error), but that's been rejected in the past due to the extra complication 
that it adds.

If we don't want to complicate the feature any further, then flags _could_ be 
used to control it, but then we'd probably need to make warn the default and 
have flags for making it an error or be ignored (or maybe even make it 
impossible to ignore, since it's a warning rather than an error). However, it 
would be bad if it were treated like a normal warning is and turned into an 
error with -w, because plenty of folks compile with -w, and so it would then 
once again become the case that deprecating anything would instantly break 
code without warning. As such, part of me wants to make it so that deprecated 
_never_ stops compilation, but you do bring up a good point that there are 
times that you need to (particularly where conditional compilation is 
concerned).

- Jonathan M Davis