Improving deprecation management

[Jonathan M Davis]

On Wednesday, November 13, 2013 20:13:43 Dicebot wrote:
> On Wednesday, 13 November 2013 at 19:02:22 UTC, Jonathan M Davis
> 
> wrote:
> > That would actually be a _big_ problem for code
> > maintainability. The same
> > compiler binary _must_ be able to compile exactly the same set
> > of programs no
> > matter when it's used. I should be able to compile exactly the
> > same set of
> > programs with a particular compiler binary ten years from now
> > as I can today.
> > Anything else will be a huge problem for real world
> > environments that use the
> > same compiler for years at a time. It's not always an option to
> > update the
> > code or the compiler, and even if it is and even if you do
> > update the code and
> > the compiler, you need to be able to reproduce old builds, and
> > that won't work
> > if deprecated symbols suddenly stop working just because the
> > date changed.
> 
> What about connecting it to date of compiler release? That will
> fix the issue and does not change much for the original proposal.

Not necessarily a bad idea, but again, Walter isn't going to go for 
complicating deprecated any further (we're arguably lucky to have what we've 
got), and given that you need to take the time to go and remove the deprecated 
symbol manually anyway, I don't think that it would really save you anything. 
With the current scheme, you can simply mark the symbol as deprecated and then 
remove it manually at some later date without having to do any other manual 
steps in between (unless you want to have the symbol undocumented but still 
there for some period of time, which adds one manual step). And since you 
really shouldn't be deprecating stuff all that frequently anyway, I don't think 
that a little extra work matters all that much.

> > And -w does _not_ turn deprecation warnings into errors (and I
> 
> just confirmed that with a simple test program).
> 
> I did not know that. That helps process a bit but makes existing
> situation even more of a mess then. One shouldn't call a warning
> what is not a warning.

You can consider it a "deprecation warning" rather than a "warning." It's not 
like we have extra terms to throw around that we can use for these things, and 
having deprecation warnings affected by -w would essentially defeat the purpose 
of making them warnings instead of errors in the first place. And without that, 
deprecating anything breaks code immediately, which for something like the 
standard library tends to mean that you can't deprecate anything.

> My problem with existing feature set is that it has created a
> whole damn zoo of compiler flags (which is bad on its own)
> without addressing one of key deprecation properties - in the
> very same application using one stuff may be an error and other
> just an informational message. It is not something that can be
> decided application-wise.

As compilers go, dmd has _very_ few flags. So, we're actually pretty well off in 
that regard. If it were up to folks like Bearophile, we'd probably have 
blizzard of flags for controlling what the compiler does and doesn't warn 
about. Walter tends to insist on flags being truly useful. It's just a shame 
that he gave in and added warnings to the compiler.

With regards to warnings and deprecation, we only have -wi, -w, and -d, so 
it's not like there are very many you have to worry about. Now, -wi should 
arguably be the default (which would remove a flag), and -w should definitely 
die IMHO, because it changes what's considered valid code - not just for the 
warning itself but because it affects what's considerd valid code for 
introspection, which can change what code gets compiled in generic code, which 
isn't good. And -d isn't anywhere near as useful as it used to be, since 
deprecation is a warning instead of an error, and it's arguably bad to make 
deprecation warnings go away, so arguably, -d should be removed as well 
(though I wouldn't expect it to be).

So, ideally, we'd get rid of -wi, -w, and -d, which would fix the flag 
proliferation in this case, but we're probably stuck with all of them given 
Walter's attitude on the matter (though maybe we could talk Walter into making 
-w act like -wi, making it redundant). However, since -wi is really the only 
one that makes sense to use, you can just use -wi and not worry about the 
others, even if we're stuck with them being in the compiler. So, while the flag 
situation with regards to warnings isn't ideal, I don't think that it's all 
that big a problem either.

- Jonathan M Davis