Opportunity

[Jonathan M Davis]

On Tuesday, April 09, 2013 00:18:32 Timothee Cour wrote:
> > I know it is hard to balance these type of errors, but unused imports and
> > variables seems a bit extreme.
> 
> seems like go won't support temporarily suppressing such errors (see
> http://weekly.golang.org/doc/faq#unused_variables_and_imports) (nor in
> fact having compile flags affecting semantics, so no
> version(identifier) constructs).
> 
> However D should have opt-in flags for those:
> --warn_unused_import
> --warn_unused_lib (for pragma lib statements)
> likewise, with error instead of warn
> 
> Is there any work on that?

No. As I understand it, Walter is against adding flags like that to dmd. He 
doesn't want a lot of stray flags which affect what is and isn't a warning and 
the like. He doesn't even like the fact that warnings exist in the first place 
- which I'm inclined to agree with. If it's something that has to be fixed, it 
should be an error, and if it doesn't have to be fix, don't warn about it, 
because any good programmer is going to have to fix all of the warnings anyway, 
ultimately making it not much different from an error anyway. Stuff like you're 
suggesting really should be left up to lint-like tools.

> --warn_unused_variable

Warning about unused variables could be a big problem, because they're heavily 
used in traits and RAII, and having -w makes _any_ kind of warnings worse, 
because they'll then affect what code does and doesn't compile.

> --warn_unused_version (for unused version identifiers, indicating a
> potentially mis-spelt version identifier given at compile time)

Impossible to warn about, because by definition, not all version identifiers are 
used at once, and users can define their own.

> --warn_unreachable_code

This is already a warning.

- Jonathan M Davis