DIP16: Transparently substitute module with package

[Steven Schveighoffer]

On Thu, 05 Apr 2012 23:18:07 -0400, Ary Manzana <ary at esperanto.org.ar>  
wrote:

> On 4/5/12 10:55 PM, Steven Schveighoffer wrote:
>> On Fri, 30 Mar 2012 10:46:19 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> Starting a new thread from one in announce:
>>>
>>> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
>>>
>>> Please comment, after which Walter will approve. Walter's approval
>>> means that he would approve a pull request implementing DIP16 (subject
>>> to regular correctness checks).
>>>
>>>
>>> Destroy!
>>
>> BTW, this case makes the part of DIP16 which wants to shortcut fully
>> qualified names invalid, or at least costly (I posted this code in
>> another part of the thread, but I thought I'd bring it up higher).
>>
>> The following is valid code today:
>>
>> a/b.d:
>>
>> module a.b;
>>
>> void foo() {}
>> struct b
>> {
>> static void foo() {}
>> }
>>
>> main.d:
>> import a.b;
>>
>> void main()
>> {
>> a.b.foo();
>> }
>>
>> If DIP16 were to be implemented, this becomes ambiguous. Is a.b.foo()
>> the module function foo() from a.b, or is it a shortcut for a.b.b.foo()?
>
> It's a shortcut to the module function foo().
>
> If I replace main.d with:
>
> void main() {
>    foo();
> }
>
> Is foo() the module function foo() from a.b, or is it a shortcut for  
> a.b.b.foo()? Here you have no doubts. What your mind does it: find a top  
> level symbol "foo" in all imported modules. If you find more than one,  
> error.

That's slightly different, because you must *always* qualify struct b's  
foo with a preceeding b.

> You must apply the same logic for "a.b.foo()". First you search "foo" in  
> the "a.b" symbol. Here you find it: it's the top level function "foo" in  
> "a.b". Then you stop searching.
>
> However, if you can't find it in the module "a.b", you search a top  
> level symbol "foo" in all modules that are in package "a.b". That's it.  
> You don't search "foo" in every possible nesting: just module nesting.

What if a.b is a struct, and it's the only possible match?  We don't  
search for it?  At some point the struct b has to come into play.  Or are  
you saying we cannot shortcut struct FQN's?

I suppose if we prefer to match modules before types, then name lookup for  
fully qualified names only becomes ambiguous with packages allowed to have  
their own modules, so it shouldn't affect existing code.

>
>>
>> The main issue is, because you can shortcut the FQN, and a chain of
>> identifiers can have repeated identifiers in them, ambiguity is  
>> possible.
>
> As I said before, it's not a shortcut of the FQN: it's just a shortcut  
> for the module name.

My example *was* a shortcut for the module name.  I did not imply that you  
could shortcut the other parts of the FQN.

What about hijacking though?  For example:

module a.b

struct c
{
    static void foo() {}
}

people now use a.c.foo() to avoid having to type the whole thing

But along comes someone who creates:

module a.c;
void foo() {}

Now, doesn't this usurp a.c.foo() without warning?

-Steve