extern(C++, ns) is wrong

[Danni Coy]

On Fri, Sep 14, 2018, 06:01 Jonathan M Davis via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

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

So extern(C++,"ns") replaces the existing syntax and then improve D's
general ability to hand functioning hijacking other functions would be the
best solution and Walters modelling of namespaces is fixing the problem in
the wrong place?

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20180915/faccded6/attachment-0001.html>