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.
