Opportunity
Paulo Pinto
pjmlp at progtools.org
Tue Apr 9 00:42:06 PDT 2013
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.
More information about the Digitalmars-d
mailing list