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
