On Wed, 10 May 2023 at 12:36, Eli Zaretskii via Gcc <gcc@gcc.gnu.org> wrote: > > > Date: Wed, 10 May 2023 10:49:32 +0200 > > From: David Brown via Gcc <gcc@gcc.gnu.org> > > > > > People who ignore warnings will use options that disable these new > > > errors, exactly as they disable warnings. So we will end up not > > > reaching the goal, but instead harming those who are well aware of the > > > warnings. > > > > My experience is that many of the people who ignore warnings are not > > particularly good developers, and not particularly good at > > self-improvement. They know how to ignore warnings - the attitude is > > "if it really was a problem, the compiler would have given an error > > message, not a mere warning". They don't know how to disable error > > messages, and won't bother to find out. So they will, in fact, be a lot > > more likely to fix their code. > > If some developers want to ignore warnings, it is not the business of > GCC to improve them, even if you are right in assuming that they will > not work around errors like they work around warnings (and I'm not at > all sure you are right in that assumption). But by _forcing_ these > errors on _everyone_, GCC will in effect punish those developers who > have good reasons for not changing the code.
There will be options you can use to continue compiling the code without changing it. You haven't given a good reason why it's OK for one group of developers to have to use options to get their desired behaviour from GCC, but completely unacceptable for a different group to have to use options to get their desired behaviour. This is just a change in defaults. Accepting broken code by default is not a priori a good thing, as you seem to insist. Rejecting it by default is not a priori a good thing. There is a pragmatic choice to be made, and your argument is still no more than "it compiles today, so it should compile tomorrow". > > > IOW, if we are targeting people for whom warnings are not enough, then > > > we have already lost the battle. Discipline cannot be forced by > > > technological means, because people will always work around. > > > > > > > Agreed. But if we can make it harder for them to release bad code, > > that's good overall. > > I'm okay with making it harder, but without making it too hard for > those whose reasons for not changing the code are perfectly valid. > This proposal crosses that line, IMNSHO. Where "too hard" means using a compiler option. Seriously? This seems farcical.
