Re: Discussion about why GNU/Linux system upgrades cause old programs to break

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > But, backwards compatibility in this instance means relaxing compiler
  > > diagnostics, thus making the compiler less strict. This is universally
  > > a disservice to users.

  > In these absolute terms I consider this statement to be wrong.

  > The alternative is not a compiler that can’t be strict, but one where
  > strictness is opt-in.

That idea sounds plausible to me.

When you're working on changes in your program P, you can enable
strictness in the compiler, and get all the diagnostics that will help
you bring it fully up to date.

Then you should release the new P with strictness disabled, to reduce
problems for the users of P.  After all, they don't know how how it works internally, so it would be hard for them to fix these things -- and we shouldn't
ask them to worry about those.

As Arne pointed out, even with his own program it is a burden to be
compelled suddenly to fix problems that appeared by surprise, in code
that functioned correctly when he was last working on that program.

  > > But, backwards compatibility in this instance means relaxing compiler
  > > diagnostics, thus making the compiler less strict. This is universally
  > > a disservice to users.

That is somewhat extremist.  Strictness in diagnostics is a benefit
for the program's developers, when they are working on that program.
But the same strictness can be a pain in the neck for other users and at
other times.

How about catering to both situations?  I think we can do it.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)