https://issues.dlang.org/show_bug.cgi?id=13605
--- Comment #3 from Ketmar Dark <[email protected]> --- (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. --
