On 4/28/2014 11:06 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Monday, 28 April 2014 at 23:57:36 UTC, Walter Bright wrote:
>> First off, I expect "std" to be put in core.stdcpp.std, and then imported. So
>> this issue would only happen if 3rd party A and 4th party B each imported 5th
>> party C. Yeah, it'll happen, and it'll still work, as the import system
>> regards the same file as being the same import regardless of the import path
>> used to get to it.
>
> No, it'll happen if they use the same vector library an #include the same
> "vector3D" and independently specify their own binding? But if they cooperate
> and use the same binding, then you are ok? That makes no sense.

I simply don't know what you're talking about when you use the word "binding".


>> It's no different than if you have:
>>
>>    A::foo()
>>
>> in one framework, and a different:
>>
>>    A::foo()
>>
>> in another framework. It won't work in C++, either.
>
> That is only true if you mangle D modules and C++ namespaces the same way.

C++ identifiers do not get the module name mangled in.


> You should be able to have A.foo and A::foo. It makes no sense to conflate the paths
> if they mangle differently.

There is no A::foo in D.


>>> The problem is that you are forced to qualify the D-binding rather than the path
>>> of the cpp function. This will only work out ok if different framework authors
>>> cooperate.
>>
>> Not correct. This is not a problem.
>
> I can mix two independent cpp bindings without casting?

Casting has nothing to do with symbol lookup.


> Why not? It only applies to the translation unit. I see no relationship.

I'm sorry, I do not understand what your mental model of how this works is. Perhaps if you wrote your questions in terms of D code examples, I can answer them.

On Tuesday, 29 April 2014 at 06:50:19 UTC, Walter Bright wrote:
>> No, it'll happen if they use the same vector library an #include the same
>> "vector3D" and independently specify their own binding? But if they cooperate
>> and use the same binding, then you are ok? That makes no sense.
>
> I simply don't know what you're talking about when you use the word "binding".

You bind the C++ extern to a D path, and as a result you get 2 types because you have 2 paths rather than one. (according to what you have said)

If they mangle to the same name then I want them to be the same type.

As a result I am better off when using pure C++ frameworks and creating my own D layer than when I am using 2 mixed D/C++ frameworks that have been developed independently.

> C++ identifiers do not get the module name mangled in.

An therefore they should be seen as the same type!

On 4/29/2014 12:10 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Tuesday, 29 April 2014 at 06:50:19 UTC, Walter Bright wrote:
>>> No, it'll happen if they use the same vector library an #include the same
>>> "vector3D" and independently specify their own binding? But if they cooperate
>>> and use the same binding, then you are ok? That makes no sense.
>>
>> I simply don't know what you're talking about when you use the word "binding".
>
> You bind the C++ extern to a D path, and as a result you get 2 types because you
> have 2 paths rather than one. (according to what you have said)
>
> If they mangle to the same name then I want them to be the same type.

The namespace contributes to the mangling of C++ symbols, but has no contribution to its type.


> As a result I am better off when using pure C++ frameworks and creating my own D
> layer than when I am using 2 mixed D/C++ frameworks that have been developed
> independently.
>
>> C++ identifiers do not get the module name mangled in.
>
> An therefore they should be seen as the same type!

The type is not a scope.

Basically, Ola, if you could write a piece of sample D code that you feel will not work, please do so.

On Tuesday, 29 April 2014 at 07:50:41 UTC, Walter Bright wrote:
> Basically, Ola, if you could write a piece of sample D code that you feel will not work, please do so.

But I did?

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?

-----
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?

On 2014-04-28 21:06, Walter Bright via Digitalmars-d wrote:
> On 4/28/2014 2:00 PM, Simen Kjærås via Digitalmars-d wrote:
>> I believe Steven expects things to work this way:
>>
>> module bar;
>>
>> extern(C++, foo) void func();
>>
>>
>> module prog;
>>
>> import bar;
>>
>> void main()
>> {
>>     foo.func(); // Calls bar.func (or is that bar.foo.func?)
>> }
>
> It would call bar.foo.func(). But your example is different from Steven's.

It is. That was kinda the point. :p

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();
}

--
  Simen

On Mon, 28 Apr 2014 17:00:11 -0400, Simen Kjærås via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 2014-04-28 20:50, Walter Bright via Digitalmars-d wrote:
>> On 4/28/2014 7:27 AM, Steven Schveighoffer wrote:
>>> Consider this code:
>>>
>>> module foo;
>>>
>>> void func() {}
>>>
>>> module bar;
>>>
>>> extern(C) func();
>>>
>>> module prog;
>>>
>>> import foo;
>>> import bar;
>>>
>>> void main()
>>> {
>>>     func(); // error
>>>     foo.func(); // ok
>>>     bar.func(); // ok, uses C binding (no name mangling)
>>> }
>>>
>>> In this case, even though the C function is not mangled or in any other
>>> namespace, the module can be used for unambiguous calling.
>>
>> Right.
>>
>>
>>> 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?
>
> I believe Steven expects things to work this way:
>
> module bar;
>
> extern(C++, foo) void func();
>
>
> module prog;
>
> import bar;
>
> void main()
> {
>     foo.func(); // Calls bar.func (or is that bar.foo.func?)
> }

Yes, exactly. That is what the DIP says:

"Declarations in the namespace can be accessed without qualification in the enclosing scope if there is no ambiguity. Ambiguity issues can be resolved by adding the namespace qualifier"

Which then  proceeds to show that only the namespace qualifier is needed to disambiguate the symbol.

-Steve

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.

On 04/29/2014 02:01 PM, Steven Schveighoffer wrote:
> That is what the DIP says:
>
> "Declarations in the namespace can be accessed without qualification in
> the enclosing scope if there is no ambiguity. Ambiguity issues can be
> resolved by adding the namespace qualifier"
>
> Which then  proceeds to show that only the namespace qualifier is needed
> to disambiguate the symbol.
>
> -Steve

You seem to be missing the only important statement that the DIP makes about symbol disambiguation, that follows straight after those examples:

"Name lookup rules are the same as for mixin templates."

(Maybe it should say 'named template mixins'.)

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

> On 04/29/2014 02:01 PM, Steven Schveighoffer wrote:
>> That is what the DIP says:
>>
>> "Declarations in the namespace can be accessed without qualification in
>> the enclosing scope if there is no ambiguity. Ambiguity issues can be
>> resolved by adding the namespace qualifier"
>>
>> Which then  proceeds to show that only the namespace qualifier is needed
>> to disambiguate the symbol.
>>
>> -Steve
>
> You seem to be missing the only important statement that the DIP makes about symbol disambiguation, that follows straight after those examples:
>
> "Name lookup rules are the same as for mixin templates."
>
> (Maybe it should say 'named template mixins'.)

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. 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