DIP16: Transparently substitute module with package

[Timon Gehr]

On 04/04/2012 07:53 PM, Steven Schveighoffer wrote:
> On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin
> <michel.fortin at michelf.com> wrote:
>
>> On 2012-04-04 14:08:34 +0000, "Steven Schveighoffer"
>> <schveiguy at yahoo.com> said:
>>
>>> The FQN cannot be ambiguous.
>>
>> Sure it can if I follow DIP16, because module names can become ambiguous.
>>
>> Let's try this with an example. First, let's define a pretty standard
>> module:
>>
>> std/algorithm/sort.d:
>>
>> module std.algorithm.sort;
>>
>> void sort(T)(T[] array);
>>
>> Here the fully-qualified name of the sort function is
>> .std.algorithm.sort.sort. But according to DIP16's lookup rules, the
>> sort function is also available (if not ambiguous) at:
>>
>> std.sort
>> std.algorithm.sort
>>
>> Question 1: since there is already a module at .std.algorithm.sort,
>> doesn't the module name become ambiguous with the sort function it
>> itself contains?
>
> 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);

>
>...
>> You might think I'm trying to split hair in four to find flaws, that
>> no one is going to do things that dumb, but I unfortunately think the
>> problematic pattern is already quite common. How many times have we
>> seen modules containing a class, variable, or function having the same
>> name as the module's name?
>
> 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.