<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>On Oct 4, 2011, at 9:27 AM, David Blaikie wrote:</div><div><div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Could/should we support -Wno-* by default anyway? I mean if we don't<br>have the warning it is certainly not on.<br>(on the other hand, as a user I wouldn't mind knowing if I'm passing<br>useless flags. Except when I'm trying to use multiple compilers and<br>turn something off in one which isn't present in the other. Minor<br>convenience to have that silently(ish) accepted on the no supporting<br>compiler)</span></blockquote></div><br></div><div><div>Hi David,</div><div><br></div>Numerous people have requested that all warnings can be placed under a -W flag, and allow them to selectively turn them on or off. I'll try and summarize why I think this is a critical feature.</div><div><br></div><div>First off, warnings are warnings. They are "added value." If a warning was truly so sacred that you cannot turn it off, in my opinion it should be an error. If you have the ability to enable a warning, you should also be able to turn it off.</div><div><br></div><div>Second, I think placing all warnings under -W flags and supporting -Wno- for all warnings enables several key workflows:</div><div><br></div><div>(1) You can use -Wall or -Weverything, and selectively disable a warning. This enables the workflow of "give me all warnings" and then turn off a few, rather than going the other way of enabling warnings in piecemeal.</div><div><br></div><div>(2) You can build your code with -Werror, and not be afraid to adopt a newer version of Clang. If you adopt a newer version of Clang and get a new warning, you have the option to turn off the warning (temporarily), allowing your code to still build but giving you time to fix your code.</div><div><br></div><div>(3) One person's warning is another person's noise. Warnings are inherently subjective. Which warning do we not allow -Wno- to support? I don't think such discussions would bear much fruit. Whenever we added a new warning, we'd have to consider whether or not to support -Wno. I also don't see how not supporting -Wno on specific warnings would provide any benefit.</div><div><br></div><div>(4) Warnings can be categorized with -W flags. Users can key off documentation based on flag names. Without a flag, all they have is the warning text, which is subject to change. Warning flags also give us a way to systematically measure when building projects which warnings fire frequently, which ones are useful, etc.</div><div><br></div><div>I can't overstate the importance of all of these, but (2) comes up very frequently for us at Apple. Without that ability, it would be *very* difficult for us to roll out new warnings. (3) is also a big concern. I've seen some developers who love warnings, and others who want to suppress whole classes of warnings because they find them annoying.</div><div><br></div><div>- Ted</div></body></html>