Opportunity

[Paulo Pinto]

On Tuesday, 9 April 2013 at 07:18:45 UTC, 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).

They something like version(identifier), you are forced to have 
separate files for each version(identifier), where identifier is 
an architecture or OS.

module.go
module_linux.go
module_windows.go
module_arm.go

Actually I prefer this way when coding in any language with 
conditional compilation support, because I have seen one too many 
#ifdef spaghetti in enterprise code.

It always starts in one single spot because of a function that 
requires different compilation support, with the amount of people 
coming and going, eventually it grows to a point where new 
developers have to take the role of the pre-processor to make any 
sense out of the code.



>
> However D should have opt-in flags for those:
> --warn_unused_variable
> --warn_unused_import
> --warn_unused_lib (for pragma lib statements)
> --warn_unused_version (for unused version identifiers, 
> indicating a
> potentially mis-spelt version identifier given at compile time)
> --warn_unreachable_code
> likewise, with error instead of warn
>
> Is there any work on that?

Seems like a nice idea.