[Issue 13605] Add ability to `version` a module declaration

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13605

--- Comment #3 from Ketmar Dark <ketmar at ketmar.no-ip.org> ---
(In reply to Mike from comment #2)
> (In reply to Ketmar Dark from comment #1)
> > what to do with this code:
> > 
> >   version(Posix) module mod;
> >   int n;
> > 
> > should it be rejected, should compiler build default module name (as it does
> > now), or something else?
> 
> What does the compiler do now if the module declaration is missing?  This
> enhancement shouldn't change anything.
ah, and here we got incinsistency!

the logic and common sense tells me that `version(Posix) module mod;` should
omit the whole module on on-posix systems. yet by the rules of the language it
will omit only module name declaration. so we faced the choice: either keep
this consistent with another `version()` usage, or made this variant special
one to resolve the inconsistency. from my POV both variants are bad.

sure, compiler can emit all sort of warnings for that cases, but this is a
clear sign of not-so-good design.

> > 'version' is not '#ifdef', and it's bad suited for such usage. i suggest to
> > use wrapper module and platform-specific modules. like this:
> > 
> >   === port.d ===
> >   module port;
> >   version(Posix) public import port.posix;
> >   else version(Win32) public import port.win32;
> >   else version(Win64) public import port.win64;
> >   else static assert(0, "no porting was done for this platform!");
> 
> This introduces a new namespace.  It's not a deal-breaker, but it's
> undesirable.
it's a question of style. i, for example, prefer to hide platform-specific
parts in another namespaces, so people will not use some platform-specific
thingy by accident.

> Agreed, but this quickly turns into `version` hell.
actually, it's not (for me). with well-designed platform-specific interfaces
most of the wrappers can be generated by various mixins. compile-time code
generation rocks! ;-)

> Have you seen some of the druntime code?
druntime is not the best sample in the world. it's not the worst either, but…
i'm using described idiom in my cross-platform code (private GUI lib, for
example) and it works fine. high-level objects and abstractions in 'gfx.d' and
low-level code in 'gfx/sdl.d', 'gfx/x11.d', etc. when code starting to becoming
messy, it rings "hey, you made something wrong in your abstract interfaces!"

> This enhancement wouldn't prevent any of the alternatives you've mentioned. 
> It does no harm.
it does *some* harm. see the first paragraph. adding special cases / breaking
"common sense" is harmful. not deadly, but still harmful.

> One of the arguments in favor of adding attributes to
> module declarations is that module declarations don't need to be anything
> special.  The same argument can be made in favor of this enhancement.  It's
> consistent with the language, and provides designers some options that
> currently don't exist.
yet you want to version out the whole module, not just module declaration. that
is the controversial point, as i see it.

--