On Wednesday, September 12, 2018 3:06:23 PM MDT Manu via Digitalmars-d wrote:
> On Tue, 11 Sep 2018 at 20:59, Danni Coy via Digitalmars-d
>
> <digitalmars-d@puremagic.com> wrote:
> > So my understanding is that the main issue with extern(C++,"ns") is functions that have different C++ name-spaces overriding each other in unexpected ways. How feasible is to simply disallow functions/variables/objects/... with the same name but a different "ns" being in the same module?
> That's natural behaviour. You can't declare the same symbol twice in the same scope.

And that's really what's so nice about the idea behind extern(C++, "NS"). It's incredibly simple, because it follows _all_ of the normal D semantics. It's just that it then affects how the symbols are mangled so that they link up with the C++ symbols that they're bindings for. So, the whole thing is incredibly easy to reason about. The only downside that I'm aware of is that it makes it harder to put multiple namespaces in the same file, which matters if you're trying to put all of the symbols from a particular header file in a corresponding module. In every other respect, it's simpler - and incredibly easy to reason about.

- Jonathan M Davis

On Thu, Sep 13, 2018, 07:06 Manu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Tue, 11 Sep 2018 at 20:59, Danni Coy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >
> >
> >
> > So my understanding is that the main issue with extern(C++,"ns") is
> functions that have different C++ name-spaces overriding each other in unexpected ways.
> > How feasible is to simply disallow functions/variables/objects/... with
> the same name but a different "ns" being in the same module?
>
> That's natural behaviour. You can't declare the same symbol twice in the same scope.
>

Sorry I meant in the instance where a function has the same name but a different signature and the wrong function might be called because of implicit promotion of a variable.

How feasible is it to have the compiler simply disallow this and force you to put such functions in different d modules?

On Wednesday, September 12, 2018 11:29:42 PM MDT Danni Coy via Digitalmars-d wrote:
> On Thu, Sep 13, 2018, 07:06 Manu via Digitalmars-d <
>
> digitalmars-d@puremagic.com> wrote:
> > On Tue, 11 Sep 2018 at 20:59, Danni Coy via Digitalmars-d
> >
> > <digitalmars-d@puremagic.com> wrote:
> > > So my understanding is that the main issue with extern(C++,"ns") is
> >
> > functions that have different C++ name-spaces overriding each other in unexpected ways.
> >
> > > How feasible is to simply disallow functions/variables/objects/... with
> >
> > the same name but a different "ns" being in the same module?
> >
> > That's natural behaviour. You can't declare the same symbol twice in the same scope.
>
> Sorry I meant in the instance where a function has the same name but a different signature and the wrong function might be called because of implicit promotion of a variable.
>
> How feasible is it to have the compiler simply disallow this and force you to put such functions in different d modules?

The entire point of having extern(C++, "NS") would be to make it so that the _only_ thing that it would affect would be the name mangling. Everything else is exactly the same behavior as it would be if you had the same functions as extern(D). It would be up to the programmer to organize them exactly like it is with pure D code. If you think that putting two functions in the same module is too risky, then you can put them in separate modules, but it certainly isn't going to be forced on you unless they actually conflict. The fact that functions are extern(C++) would have no impact on that whatsoever.

- Jonathan M Davis

On Thu, Sep 13, 2018 at 5:14 PM Jonathan M Davis via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

>
>
> The entire point of having extern(C++, "NS") would be to make it so that
> the
> _only_ thing that it would affect would be the name mangling. Everything
> else is exactly the same behavior as it would be if you had the same
> functions as extern(D). It would be up to the programmer to organize them
> exactly like it is with pure D code. If you think that putting two
> functions
> in the same module is too risky, then you can put them in separate modules,
> but it certainly isn't going to be forced on you unless they actually
> conflict. The fact that functions are extern(C++) would have no impact on
> that whatsoever.
>

Yeah I get all this. It just seems to me that the downsides of
extern(C++,"ns") from Walter's point of view could be handled by the
compiler at the cost of a bit of flexibility.
I would like to know how difficult that would be to do and whether that
would be more acceptable to Walter than what is being being proposed.

On Thursday, September 13, 2018 5:45:56 AM MDT Danni Coy via Digitalmars-d wrote:
> On Thu, Sep 13, 2018 at 5:14 PM Jonathan M Davis via Digitalmars-d <
>
> digitalmars-d@puremagic.com> wrote:
> > The entire point of having extern(C++, "NS") would be to make it so that
> > the
> > _only_ thing that it would affect would be the name mangling. Everything
> > else is exactly the same behavior as it would be if you had the same
> > functions as extern(D). It would be up to the programmer to organize
> > them
> > exactly like it is with pure D code. If you think that putting two
> > functions
> > in the same module is too risky, then you can put them in separate
> > modules, but it certainly isn't going to be forced on you unless they
> > actually conflict. The fact that functions are extern(C++) would have
> > no impact on that whatsoever.
>
> Yeah I get all this. It just seems to me that the downsides of
> extern(C++,"ns") from Walter's point of view could be handled by the
> compiler at the cost of a bit of flexibility.
> I would like to know how difficult that would be to do and whether that
> would be more acceptable to Walter than what is being being proposed.

I don't know what Walter would go for, but trying to do anything special for extern(C++, "NS") symbols pretty much defeats the whole purpose of using extern(C++, "NS") over extern(C++, NS). And the issue that you are trying to find a way to prevent is something that D code in general has to worry about, so I don't think that it makes any sense to try to treat extern(C++) symbols as special to try to fix it.

If we have extern(C++, "NS"), then anyone creating C++ bindings will have to worry about conflicts in exactly the same way that they would with D code. You have to do that with extern(C++, NS) too. It's that it's then only with the functions within that namespace.

Walter's concerns seem to center around the idea that we somehow need to model C++ namespaces in D, so that's really what needs to be addressed somehow. The D module system gives us everything we need to lay out symbols so that they don't conflict. The only thing that it can't do is allow you to put conflicting symbols in the same module, making it harder to have a 1-to-1 correspondance between D modules and C++ header files in rare cases, but all we need to do to solve that is to either leave in extern(C++, NS) for those cases or to make it so that something like

static NS1
{
    extern(C++, "NS1") static void foo(int bar);
}

static NS2
{
    extern(C++, "NS2") static void foo(int bar);
}

works (which is basically what extern(C++, NS) is doing anyway). But honestly, in most cases, it just makes more sense to split up the symbols between modules, and in the vast majority of cases, you simply don't have multiple namespaces with conflicting symbols in the same header file.

- Jonathan M Davis

On Thu, 13 Sep 2018 at 13:01, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> Walter's concerns seem to center around the idea that we somehow need to model C++ namespaces in D, so that's really what needs to be addressed somehow. The D module system gives us everything we need to lay out symbols so that they don't conflict. The only thing that it can't do is allow you to put conflicting symbols in the same module, making it harder to have a 1-to-1 correspondance between D modules and C++ header files in rare cases,

But consider the overwhelmingly common case where C++ namespaces span
across many files.
You can't distribute extern(C++, ns) across D modules, so D fails to
model C++ namespaces regardless, and in the vast majority case. The
minority case you point out above is irrelevant by contrast.
The current design fails at its primary goal right out of the gate,
but we wear a pile of super-anger-inducing baggage in its wake.

On Thu, 13 Sep 2018 at 04:46, Danni Coy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Thu, Sep 13, 2018 at 5:14 PM Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> The entire point of having extern(C++, "NS") would be to make it so that the _only_ thing that it would affect would be the name mangling. Everything else is exactly the same behavior as it would be if you had the same functions as extern(D). It would be up to the programmer to organize them exactly like it is with pure D code. If you think that putting two functions in the same module is too risky, then you can put them in separate modules, but it certainly isn't going to be forced on you unless they actually conflict. The fact that functions are extern(C++) would have no impact on that whatsoever.
>
> Yeah I get all this. It just seems to me that the downsides of extern(C++,"ns") from Walter's point of view could be handled by the compiler at the cost of a bit of flexibility.

What are the 'downsides' you refer to? And what 'flexibility' is lost? The whole point is to gain flexibility. There's definitely no loss of flexibility on the table here ;)

> I would like to know how difficult that would be to do and whether that would be more acceptable to Walter than what is being being proposed.

You'll need to elaborate. What is being proposed is the simplest possible, most plainly obvious, let's-not-introduce-unwieldy-edge-cases solution.

Walters named scope should be an unrelated and parallel feature if he really wants it.

On Thursday, September 13, 2018 4:43:47 PM MDT Manu via Digitalmars-d wrote:
> On Thu, 13 Sep 2018 at 13:01, Jonathan M Davis via Digitalmars-d
>
> <digitalmars-d@puremagic.com> wrote:
> > Walter's concerns seem to center around the idea that we somehow need to model C++ namespaces in D, so that's really what needs to be addressed somehow. The D module system gives us everything we need to lay out symbols so that they don't conflict. The only thing that it can't do is allow you to put conflicting symbols in the same module, making it harder to have a 1-to-1 correspondance between D modules and C++ header files in rare cases,
> But consider the overwhelmingly common case where C++ namespaces span
> across many files.
> You can't distribute extern(C++, ns) across D modules, so D fails to
> model C++ namespaces regardless, and in the vast majority case. The
> minority case you point out above is irrelevant by contrast.
> The current design fails at its primary goal right out of the gate,
> but we wear a pile of super-anger-inducing baggage in its wake.

I'm not disagreeing, but I'm not the person who needs to be convinced. Either way, a DIP needs to be produced which

1. really clearly explains the semantics (which shouldn't be hard given
their simplicity).

2. does an excellent job of explaining the downsides to the current approach, why they're such a big problem, why workarounds for those problems are terrible, and why the proposed approach doesn't have those same problems.

3. and of course, for thoroughness, it needs to explain the downsides to the proposed approach and the likely workarounds, but the issue of trying to put multiple namespaces in a single module when they were in a single header file is the only downside that I'm aware of.

How easy it's going to be to put something together that convinces Walter, I don't know, but we clearly need a well-written DIP to stand a chance, and I have no clue what arguments would convince Walter. I don't know what Andrei thinks on the subject, but maybe the trick is to write the DIP so well that Andrei is convinced, and then _he_ convinces Walter. And maybe we'll get lucky, and after Walter mulls over it enough, he'll come around. I don't know.

Either way, I don't think that you really need to convince many folks who have actually dealt with extern(C++, NS). At least out of those folks who say anything in the forums, it seems that pretty much anyone (other than Walter) who looks into the issue much pretty quickly comes to the conclusion that the current approach is terrible. It's Walter who is clearly hard to convince.

- Jonathan M Davis

On Thursday, 13 September 2018 at 23:30:33 UTC, Jonathan M Davis wrote:
> On Thursday, September 13, 2018 4:43:47 PM MDT Manu via Digitalmars-d wrote:
>> [...]
>
> I'm not disagreeing, but I'm not the person who needs to be convinced. Either way, a DIP needs to be produced which
>
> [...]

As someone who does a lot of c/c++ binding I am 100% in favor of Manu's extern(C++, "ns")
I also want to point out that extern should work in mixins (see bug https://issues.dlang.org/show_bug.cgi?id=12575).
So probably a good idea to clearify interactions like that in a DIP as well.

- Zot

On Friday, 14 September 2018 at 09:56:52 UTC, Zot wrote:
> On Thursday, 13 September 2018 at 23:30:33 UTC, Jonathan M Davis wrote:
>> On Thursday, September 13, 2018 4:43:47 PM MDT Manu via Digitalmars-d wrote:
>>> [...]
>>
>> I'm not disagreeing, but I'm not the person who needs to be convinced. Either way, a DIP needs to be produced which
>>
>> [...]
>
> As someone who does a lot of c/c++ binding I am 100% in favor of Manu's extern(C++, "ns")
> I also want to point out that extern should work in mixins (see bug https://issues.dlang.org/show_bug.cgi?id=12575).
> So probably a good idea to clearify interactions like that in a DIP as well.
>
> - Zot

I'm also completely in favour of what Manu is saying. The current situation works for no one. I very much doubt that any D programmer exists that wants what extern(C++) currently does.

Yes, C++ namespaces are a mess. Who cares? We have modules. All we want is to be able to link.

Walter pointed out workarounds, but: they're solutions to a problem that shouldn't exist; are ugly as sin; aren't even sufficient for manually writing bindings in the way the author intends.

Forum chatter won't do it though, we need a DIP.