I know some people feel strongly that variable name shadowing should not generate a warning, but I just wasted a non-trivial amount of time as a result of: ovrTracking2 * tracking = &tracking[displaySequence % MAX_INFLIGHT];
-
-
Advantage of warnings is that they can be introduced without rewriting spec which takes time (and might be politically impossible, for backwards compatibility). Running with "treat warnings as errors" is the only sane option.
-
While I don’t disagree with warnings-as-errors, each compiler has its own idea of what warnings are available and when they’re emitted, which makes warnings as errors hurt code portability, requiring more effort to get code to compile. Solved by switching to clang everywhere :)
End of conversation
New conversation -
-
-
We have pretty much made each warning either an error, or silenced. I see no other reasonable way for a team with many devs
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Error \o/ Fixing the spec is the right long-term solution, but that might be too idealistic? See Python and JavaScript. People use linters to fix these languages until they evolve, but that might never happen
-
You don’t want to churn the spec too frequently, though. I think there’s value in getting new warnings faster than you’d want the spec to rev.
End of conversation
New conversation -
-
-
Are you against warnings entirely? The useful thing about warnings is that compilers can add new ones faster than the language spec evolves. Some will fire in old code, and now you get to make the call what to do.
-
Does anyone actually upgrade compilers and not expect to have to change their code?
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.