On Wed, 04 Apr 2012 14:03:07 -0400, Timon Gehr <timon.g...@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
