On 04/29/2014 05:52 PM, Steven Schveighoffer wrote:
> I am not familiar with the rules.
>
> Perhaps you can just outline for me:
>
> module bar;
>
> extern(C++, foo) void func();
>
> module prog;
>
> import bar;
>
> void main()
> {
>     foo.func(); // works?
> }
>
> If this works, then we have a problem.

It does work. What happens is analogous to:

module bar;

void func(){}

module prog;
import bar;

void func(){}

void main(){
    func();
}

I.e. if you add a new symbol to your own module, then this identifier will be hidden, no questions asked. Importing a module adds a new symbol of its name to your module. I'm not sure why you see this as a problem. The name lookup rules are designed such that changes in one module cannot silently change name lookup in _another_ module, but anything may happen to lookup in the same module.

> If it doesn't work, well, then I
> see nobody using this feature (using C++ namespace for disambiguation,
> not the mangling, which is still useful).
>
> -Steve

The name disambiguation feature fundamentally addresses one simple issue, namely the case when the same name occurs in multiple different namespaces occurring in the same module. (It is trivial to implement in a compiler, if that helps, because there is no new machinery, just share the implementation with named mixin templates.)

On Tue, 29 Apr 2014 12:03:02 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 04/29/2014 05:52 PM, Steven Schveighoffer wrote:
>> I am not familiar with the rules.
>>
>> Perhaps you can just outline for me:
>>
>> module bar;
>>
>> extern(C++, foo) void func();
>>
>> module prog;
>>
>> import bar;
>>
>> void main()
>> {
>>     foo.func(); // works?
>> }
>>
>> If this works, then we have a problem.
>
> It does work. What happens is analogous to:
>
> module bar;
>
> void func(){}
>
> module prog;
> import bar;
>
> void func(){}
>
> void main(){
>      func();
> }
>
> I.e. if you add a new symbol to your own module, then this identifier will be hidden, no questions asked. Importing a module adds a new symbol of its name to your module. I'm not sure why you see this as a problem. The name lookup rules are designed such that changes in one module cannot silently change name lookup in _another_ module, but anything may happen to lookup in the same module.

OK, so you are saying that from a module different than the one that defines the namespace/function, I can call it via it's full namespace.

But what happens when you add another import that conflicts?

module foo;

void func() {}

module prog; // updated
import bar;
import foo;

void main(){
   foo.func(); // now calls foo.func, and not bar.func as it originally did, right?
}

So by importing from another module, we have silently and drastically changed the behavior. Have I missed something?

Why is this not a problem?

-Steve

On 4/29/2014 2:01 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> framework1.d:
> extern(C++,veclib){ struct … vec4 …; }
> extern(C++,physics){ vec4 f(vec4 …) … }
>
> framework2.d:
> extern(C++,veclib){ struct … vec4 …; }
> extern(C++,graphics){ void g(vec4 …) … }
>
> application1.d:
> import framework1;
> import framework2;
>
> graphics.g( physics.f(…) ); // you said this would not work?

That won't work because framework1.veclib.vec4 is not the same as framework2.veclib.vec4, as far as D's symbol lookup is concerned.


> -----
> myframework.d
> extern(C++,veclib){ struct … vec4 …; }
> extern(C++,physics){ vec4 f(vec4 …) … }
> extern(C++,graphics){ void g(vec4 …) … }
>
> application2.d
> import myframework;
>
> graphics.g( physics.f(…) ); // but now it works?

Yes, because now there is only one myframework.veclib.vec4.

I'd do your example as:

vec.d:
extern(C++,veclib){ struct … vec4 …; }

framework1.d:
import vec;
extern(C++,physics){ vec4 f(vec4 …) … }

framework2.d:
import vec;
extern(C++,graphics){ void g(vec4 …) … }

application1.d:
import framework1;
import framework2;

graphics.g( physics.f(…) );  // works

On 4/29/2014 8:43 AM, Timon Gehr wrote:
> as the DIP _does not actually introduce any new lookup rules_
>  [...]
> In particular, any problems you find with symbol lookup are actually orthogonal
> to the DIP.

Yes!

On 4/29/2014 9:13 AM, Steven Schveighoffer wrote:
> But what happens when you add another import that conflicts?
>
> module foo;
>
> void func() {}
>
> module prog; // updated
> import bar;
> import foo;
>
> void main(){
>     foo.func(); // now calls foo.func, and not bar.func as it originally did,
> right?
> }
>
> So by importing from another module, we have silently and drastically changed
> the behavior. Have I missed something?
>
> Why is this not a problem?

Because the compiler would now issue an error for that, it's its anti-hijacking feature.

Try it and see!

On Tue, 29 Apr 2014 15:52:01 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/29/2014 9:13 AM, Steven Schveighoffer wrote:
>> But what happens when you add another import that conflicts?
>>
>> module foo;
>>
>> void func() {}
>>
>> module prog; // updated
>> import bar;
>> import foo;
>>
>> void main(){
>>     foo.func(); // now calls foo.func, and not bar.func as it originally did,
>> right?
>> }
>>
>> So by importing from another module, we have silently and drastically changed
>> the behavior. Have I missed something?
>>
>> Why is this not a problem?
>
> Because the compiler would now issue an error for that, it's its anti-hijacking feature.
>
> Try it and see!

I agree! that was my central point, which Timon seemed to be arguing against :)

Quoting:

On Tue, 29 Apr 2014 11:43:45 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 04/29/2014 01:34 PM, Simen Kjærås via Digitalmars-d wrote:
>>
>> Building on this knowledge:
>>
>> module foo;
>>
>> void func();
>>
>>
>> module bar;
>>
>> extern(C++, foo) void func();
>>
>>
>> module prog;
>>
>> import foo;
>> import bar;
>>
>> void main()
>> {
>>      // Seems like it's ambiguous between foo.func and bar.foo.func.
>>      foo.func();
>> }
>
> It will call foo.func, because the module foo is in scope in module prog and hence hides the namespace foo in module bar.
>
> You can already try this today, as the DIP _does not actually introduce any new lookup rules_:
>
> module a;
> void func(){}
> //---
> module bar;
>
> mixin template X(){
>      void func();
> }
> mixin X foo;
> //---
> import foo,bar;
>
> void main(){
>      foo.func();
> }
>
> In particular, any problems you find with symbol lookup are actually orthogonal to the DIP.


-Steve

On Tuesday, 29 April 2014 at 19:48:36 UTC, Walter Bright wrote:
> I'd do your example as:
>
> vec.d:
> extern(C++,veclib){ struct … vec4 …; }
>
> framework1.d:
> import vec;
> extern(C++,physics){ vec4 f(vec4 …) … }
>
> framework2.d:
> import vec;
> extern(C++,graphics){ void g(vec4 …) … }

Yes, but that requires the authors of framework1 and framework2 to cooperate. Which is why you with this DIP will end up with people being better off by using pure C++ rather than mixed D/C++ from different sources.

With "graphics::g(physics::f(…))" this would not have been an issue.

On 4/29/2014 1:23 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Tuesday, 29 April 2014 at 19:48:36 UTC, Walter Bright wrote:
>> I'd do your example as:
>>
>> vec.d:
>> extern(C++,veclib){ struct … vec4 …; }
>>
>> framework1.d:
>> import vec;
>> extern(C++,physics){ vec4 f(vec4 …) … }
>>
>> framework2.d:
>> import vec;
>> extern(C++,graphics){ void g(vec4 …) … }
>
> Yes, but that requires the authors of framework1 and framework2 to cooperate.

Not really. It is reasonable to expect that when Framework1 and Framework2 each import 4th party Vec, that they do it with an import rather than inlining Vec's declarations.


> Which is why you with this DIP will end up with people being better off by using
> pure C++ rather than mixed D/C++ from different sources.
>
> With "graphics::g(physics::f(…))" this would not have been an issue.

Having an alternative lookup method is a large increase in language complexity.

On 4/29/2014 1:33 PM, Walter Bright wrote:
> On 4/29/2014 1:23 PM, "Ola Fosheim Grøstad"
>> With "graphics::g(physics::f(…))" this would not have been an issue.

It does occur to me that two C++ symbols in the same namespace may be regarded as the same by the lookup code. That may be a reasonable enhancement request.

On Tue, 29 Apr 2014 16:00:43 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Tue, 29 Apr 2014 15:52:01 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

>> Because the compiler would now issue an error for that, it's its anti-hijacking feature.
>>
>> Try it and see!
>
> I agree! that was my central point, which Timon seemed to be arguing against :)

And in fact, so were you!

On Mon, 28 Apr 2014 16:50:45 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/28/2014 7:27 AM, Steven Schveighoffer wrote:
>> module foo;
>>
>> void func() {}
>>
>> module bar;
>>
>> extern(C++, foo) void func(); // foo::func in C++ land
>>
>> module prog;
>>
>> import foo;
>> import bar;
>>
>> void main()
>> {
>>     func(); // error
>>     foo.func(); // ALSO error
>
> No, not an error. Why would it be?

This is EXACTLY the same code that you said would now be an error above!

I think you guys need to reexamine this, and choose one way or another. At this point, I have no clue as to how it's supposed to work.

-Steve