DIP16: Transparently substitute module with package

[Steven Schveighoffer]

On Wed, 04 Apr 2012 14:03:07 -0400, Timon Gehr <timon.gehr at gmx.ch> wrote:

> On 04/04/2012 07:53 PM, Steven Schveighoffer wrote:
>> OK, but when is it ever valid to refer to a module when the semantic
>> expectations are for something other than a module? I can only think of
>> two places where module names are used, inside an import statement and
>> inside a module statement (three if you count the prefix of a FQN).
>> Maybe I'm missing some case...
>
> __traits(allMembers, pack.age.mod.ule);

hm... maybe we'd have to have new __traits that would disambiguate, like  
__traits(allModuleMembers...)

This doesn't seem like a huge barrier.

>
>>
>> Tango anyone? :) But yes, I think the issue really becomes, we need to
>> look at context when deciding the semantic meaning of a symbol. I don't
>> think this violates the context-free grammar, because wouldn't this only
>> come into play at the semantic level? Not a compiler writer/hacker, so I
>> don't know.
>
> No symbol is resolved until semantic, but I don't think hiding the  
> module/package symbol if any clashing symbol in the module/any  
> subpackage exists is a satisfactory solution.

Then we must come up with a way to hide the submodules of a virtual module.

I tried this, which fails on the current compiler:

import x;

int x;

So it seems we have two choices here:

1. DIP16 needs to get more complex to make package submodules not  
accesible as individual modules.
2. Start contextually interpreting identifiers at least in the case of  
modules vs. non-modules.

I'd suggest option 2 allows for better backwards compatibility and more  
flexibility.

-Steve