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

Ketmar Dark <ketmar@ketmar.no-ip.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ketmar@ketmar.no-ip.org

--- Comment #1 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
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?

'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!");

  === port/posix.d ===
  module port.posix;
  version(Posix):
  // posix code follows

  === port/win32.d ===
  module port.win32;
  version(Win32):
  // win32 code follows

and so on.

this way you can build your code on all platforms passing all source files to build command, yet you get only that code which is relevant to your destination platform. and you can write all platform-independend code in "port.d".

note "public import" here, which makes platform-specific imports public, so you can define function `foo()` for each platform independently.

note: i suggest to avoid such public imports, though. it's better to write wrappers in "port.d" which calls platform-specific `foo()`. there are some problems with public imports with renamings and such.

--

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

--- Comment #2 from Mike <slavo5150@yahoo.com> ---
(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.

> 
> '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.

> 
> note: i suggest to avoid such public imports, though. it's better to write wrappers in "port.d" which calls platform-specific `foo()`. there are some problems with public imports with renamings and such.

Agreed, but this quickly turns into `version` hell.  It doesn't scale well. Have you seen some of the druntime code?  Again, it's not a deal-breaker, but it's undesirable.

This enhancement wouldn't prevent any of the alternatives you've mentioned.  It does no harm.  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.

--

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

--- Comment #3 from Ketmar Dark <ketmar@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.

--

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

--- Comment #4 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
p.s. i see the point in your request, though. i'm just not sure that it will be better to change the status quo.

--

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

--- Comment #5 from Mike <slavo5150@yahoo.com> ---
(In reply to Ketmar Dark from comment #3)
> (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.

Programmers who understand the grammar of the language will have no problem here.  There's no reason to think modules declarations are special, and therefore no inconsistency or ambiguity.

--

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

--- Comment #6 from Mike <slavo5150@yahoo.com> ---
(In reply to Ketmar Dark from comment #4)
> p.s. i see the point in your request, though. i'm just not sure that it will be better to change the status quo.

This enhancement does not propose any change to the status quo.  It just proposes removing an arbitrary limitation from the language.

--

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

--- Comment #7 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
(In reply to Mike from comment #5)
> Programmers who understand the grammar of the language will have no problem here.  There's no reason to think modules declarations are special, and therefore no inconsistency or ambiguity.
it reminds me recent discussion about prefix attributes. grammar for prefix 'const' is clear too, yet people want 'const' to go. despite all "consistency". for the same reasons i'm against this ER.

--

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

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--- Comment #8 from hsteoh@quickfur.ath.cx ---
You do realize that in D, the module name must match the source filename, right? So your proposed solution won't work.

The recommended way to achieve what you want is as follows:

----port_linux.d----
module port_linux;
... // Linux stuff here

----port_windows.d----
module port_windows;
... // Windows stuff here

----port.d----
version(linux)
    public import port_linux;
version(Windows)
    public import port_windows;

----main.d----
import port; // will pull in correct version of stuff depending on platform
void main() { ... }

--

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

Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com

--- Comment #9 from Andrej Mitrovic <andrej.mitrovich@gmail.com> ---
(In reply to hsteoh from comment #8)
> You do realize that in D, the module name must match the source filename, right?

I haven't followed the proposal, but this is actually wrong. The module name doesn't have to named the same, it's also described as a feature in TDPL.

Personally I'm against it though.

--

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

Mike <slavo5150@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |bare-metal

--