On Saturday, 1 November 2014 at 15:32:22 UTC, Dicebot wrote:
On Saturday, 1 November 2014 at 14:48:33 UTC, Nicolas Sicard
wrote:
On Saturday, 1 November 2014 at 14:40:16 UTC, Dicebot wrote:
On Saturday, 1 November 2014 at 14:03:51 UTC, Nicolas Sicard
wrote:
What's the reason why the module keyword was introduced in
the first place? The package and module hierarchy could have
been deduced from the directory and file hierarchy, as it is
the case in Python, IIRC. The search rules just have to be
clear. I know this has the side effect that module names
can't be keywords or non-identifiers, but who would use such
module names?
You can omit module declarations and those will be deduced
indeed.
However that will make package path dependent on compiler
currend directory and this is why specifying qualified path
explicitly is helpful.
Compiling is already dependent on the current directory. And
qualified path are not just helpful, they're required for
packages, or did I miss something?
Ah yes, damnation, I keep forgetting about this one. In my
opinion it is a bug and it should indeed use reative folder
path as package name. However fixing it can be hard because of
possible build system breakage and stuff. Would be interesting
to check that with dub & Co.
Actually, I don't think it's a bug. The current model is
coherent: a package must be bound to a top-level directory. So
the modules in the package must specify what this top-level
directory is.
What I meant is that I don't know what would be wrong in being
able to do "dmd -I/path/to/phobos/std" and "import stdio;", that
is if relative folder paths were used. The module statement
wouldn't be necessary (apart for files like foo-bar.d). I
should've asked in d.learn :)
