> 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 <[email protected]> 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. > >
