Bug 10147 – Make -w identical to -wi and deprecate it

-w is inherently broken, because it changes the semantics of code when static inference and conditional compilation and whatnot are involved. -wi is by far the smarter approach, and I really don't think that -w should have existed in the first place. But given that we have it (and it predates -wi), removing it at this point would break a lot of projects. So, I propose that we simply make it so that -w does the same thing as -wi and deprecate it. It's at least _possible_ that some code will break due to the change in semantics, but it's that change in semantics that we want to eliminate, and for the most part, code breakage is unlikely (and arguably would be desirable given the semantics changes of using -w). So, with -w deprecated, projects can migrate to using -wi, which won't change their code's semantics, and we can possibly remove -w at some point in the future (or just remove it from the docs if we don't want to go the extra step of removing it). In any case, I think that we would be far better of with -w and that we should at least seriously consider getting rid of it, and making it the same as -wi seems like a good step in that direction to me.

> -w is inherently broken, because it changes the semantics of code when static inference and conditional compilation and whatnot are involved. Can you please be more specific, maybe with example code? I have no knowledge of any of this..

> Can you please be more specific, maybe with example code? I have no knowledge > of any of this. Okay. Let's say that you have a function like auto foo(T)(T t) { switch(t.val) { case 1: writeln("warnings"); case 2: writeln("become"); case 3: writeln("errors"); default: break; } return t.ret; } Without -w, this code will compile just fine (assuming that T has a member called val which works with a switch statement as well as a member called ret). But with -w, it won't compile thanks to the fact that it uses implicit fallthrough. Now, say you have a function like auto bar(T)(T t) if(is(typeof(foo(T.init)))) { ... } The template constraint passes if the argument compiles with foo and fails if it doesn't. So, without -w, if you have the type struct S { int val; int ret; } and you pass it to bar, the code will compile. But if you compile with -w, it won't, because foo no longer compiles thanks to implicit fallthrough becoming an error. _Anything_ that tests whether code compiles potentially breaks thanks to -w. How big a problem this is in practice, I don't know, but -w can change the semantics of code, meaning that whether you compile with -w or not effectively creates two different languages. Normally, we reject any suggestions that involve flags like this. -w really makes no sense.

That seems like a problem with lack of testing from the developer. GCC has similar features like -pedantic-errors and -Werror= (http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Warning-Options.html). I'd hate to have to manually abort the compiler process on the first warning message.

> That seems like a problem with lack of testing from the developer. In this case, yes, but there may be cases where that's not true. But if even there aren't, it means that we have a flag which changes what's legal in the language and therefore potentially changes the semantics of code, which risks bugs without good reason IMHO. > GCC has similar features like -pedantic-errors and -Werror= > (http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Warning-Options.html). C++ doesn't have the compile time introspection capabilities that D has, so it wouldn't have as many issues with it. If it's really only a matter of make it so that no object code is generated when I have have warnings, then that wouldn't be a big deal, but in D, it actually affects the semantics of the program. And it wouldn't even necessarily change them in a way that causes the program to not compile. It could be that it would result in simply taking the wrong/inefficient overload without the programmer knowing. e.g. auto foo(T)(T t) if(isBar!T) {...} auto foo(T)(T t) if(!isBar!T) {...} > I'd hate to have to manually abort the compiler process on the first warning > message. I don't follow. Why would anything have to be manually aborted?

(In reply to comment #4) > I don't follow. Why would anything have to be manually aborted? Well if -w no longer aborts compilation on the first warning, it means the compiler will continue compiling. So if it takes 10 seconds to compile something I have to manually kill the compiler process on the first warning if I want to save some time. Also, what if I *want* compilation to fail on e.g. switch fallthrough? Actually I don't even know why that is a warning instead of an error, who wants bugs in their code?

Oh, I'd love to get rid of both -w and -wi and just make everything a warning or nothing, but I don't expect that to happen at this point. Switch fallthrough might become a full error at some point though. Another alternative would be to make it so that -w stops compilation like it would with an error, but it has no effect on compile-time introspection or any other semantics. I don't know how easy it would be to do that in the compiler though.

*** Issue 10321 has been marked as a duplicate of this issue. ***

I have closed down my Issue 10321 because despite it's not exactly a duplicated, I think it's better to aggregate them. Summarizing, the needs and problems are: - You have explained well why the "-w" warning is bad. - Lot of people don't see the warnings switch of the compiler, so they don't see the warnings, and this makes their programs worse or they don't understand some other errors that are generated later. So I believe the informational warnings should be active on default (and the compiler should have a switch to disable them in the rare cases when you don't want them). - On the other hand Andrej Mitrovic (and probably others, now or in future) want a switch like in GCC that halts the compilation at the first warning. I think this is not a common need, but it exists. I don't know how to make this work considering the problems of the "-w" switch.

(In reply to comment #8) > - On the other hand Andrej Mitrovic (and probably others, now or in future) > want a switch like in GCC that halts the compilation at the first warning. I > think this is not a common need, but it exists. I don't know how to make this > work considering the problems of the "-w" switch. Hmm thinking about this some more I think the only reason I've ever needed -w was because of issues like missing default switch and switch case fall-through (and perhaps missing override keyword), which IIRC used to be warnings but are now finally deprecated behavior. Some warnings in DMD should have been errors from the get-go. I don't think many (if any?) warnings are left that should be errors, and this was the only reason why I needed -w.

(In reply to comment #9) > Hmm thinking about this some more I think the only reason I've ever needed -w > was because of issues like missing default switch and switch case fall-through > (and perhaps missing override keyword), which IIRC used to be warnings but are > now finally deprecated behavior. > > Some warnings in DMD should have been errors from the get-go. I don't think > many (if any?) warnings are left that should be errors, and this was the only > reason why I needed -w. Some new warnings (and later deprecations) will be added because there are more than one thousand issues open and some of them are about small D design mistakes that I really hope will eventually be fixed.

(In reply to comment #2) > > Can you please be more specific, maybe with example code? I have no knowledge > > of any of this. > > Okay. Let's say that you have a function like > > [...] > > _Anything_ that tests whether code compiles potentially breaks thanks to -w. > How big a problem this is in practice, I don't know, but -w can change the > semantics of code, meaning that whether you compile with -w or not effectively > creates two different languages. Normally, we reject any suggestions that > involve flags like this. -w really makes no sense. Couldn't we instead "fix" "-w" ? Currently, it transforms any warning into an error, creating the above mentioned problem. What we *really* want (as stated by Andrej) is simply for compilation to halt on the first reported warning. If we simply "upgrade" -w to work as in "if a warning is *emitted*, then translate that warning into an error, and then halt compilation. This means we'd have 100% the same behavior between "", "-w", "-wi", but still get the behavior of "I refuse to compile until you process this warning". I'm not compiler savvy, so wouldn't know how easy it is to improve it to do this, but it seems better than to simply deprecate it...

I consider the very existence of warnings a mistake. Their use cases are completely taken over by static analysis tools. I think the idea solution would have been to go through the list of warnings and make some of them errors. Remaining ones should stay available only as -wi and once standard static analysis tool will appear - completely moved there.

I would _love_ it if we got rid of warnings completely, and I know that Walter has similar feelings. I believe that we have them primarily because Walter got bullied into it, and that's likely why dmd has such abnormal behavior with regards to warnings. What every other compiler I've ever used does is _always_ emit warnings, and if there's a flag for making them errors, it's not normally used. Warnings are horrible, because they aren't things that are necessarily actually wrong, and yet you're then forced to fix them, because it's bad practice (and hides legitimate problems) if you leave a bunch of warnings in your code. So, ultimately, there's not much difference between an error and a warning. We'd be _far_ better off without them. I completely agree with Dicebot that anything which is not _guaranteed_ to be wrong should be done with a static analysis tool. That being said, if we're stuck with -w and/or -wi, -w needs to fixed - either by fixing its behavior so that it has no effect on conditional compilation or by getting rid of it in favor of just having -wi.

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18584 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB