Improving deprecation management

[Dicebot]

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.

> 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.

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.