module keyword with curly brackets

[Nicolas Sicard via Digitalmars-d]

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 :)