On 04/04/2012 07:53 PM, Steven Schveighoffer wrote:
On Wed, 04 Apr 2012 12:33:26 -0400, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2012-04-04 14:08:34 +0000, "Steven Schveighoffer"
<schvei...@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.
