Opportunity

[Timothee Cour]

> 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.
The problem is mitigated in D because conditional compilation follows
the language scoping. So the benefits of DRY code outweigh the added
complexity, which is very minor with proper IDE support: visualD
supports graying out bad code blacks that are known statically to be
false, and I've just made similar enhancement request for monod, see
https://github.com/aBothe/Mono-D/issues/269
(working on that with Alexander Bothe)

On Tue, Apr 9, 2013 at 12:42 AM, Paulo Pinto <pjmlp at progtools.org> wrote:
> 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.
>
>