extern(C++, ns)

[Manu via Digitalmars-d]

On 13 January 2016 at 03:20, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 1/11/2016 8:02 PM, Manu via Digitalmars-d wrote:
>>
>> Surely the fact that people are implementing machinery to undo the
>> damage done is a strong indication that they don't want the feature.
>> Please, can anyone produce an argument in favour...? Otherwise just
>> accept that it was a bad idea and eject it into space.
>> Why could anyone be attached to it?
>
>
>
> I already did for your scheme:
>
>   int a;
>   extern (C++,ns) { int a; }  // error!

Of course that's an error, declaring 2 symbols with the same name at
the top level of the same module is obviously an error. No D coder
would expect otherwise.
There's no realistic scenario that could lead to that case; why would
you have an extern(C++) symbol in some module and also want to put a D
symbol with the same name in the same place? The only case I can
imagine is you might want an extern(D) overload which wraps an
extern(C++) function, but that works fine so there's no issue there.

> The whole point of namespaces in C++ is to introduce scoped names.

But we already have scoped names in D, so implementing that semantic
for that reason has no value in D. We just want to link to C++ code.
We don't want C++ concepts invading D, especially when the problem is
already solved.
We have a well defined module system. There's no reason, and no desire
to deviate from that in any way whatsoever.
I suggest that, if you're convinced namespaces must exist to address
the non-issue you present above, then it should be a separate opt-in
feature. As far as I know, we're yet to hear from someone who wants
that behaviour by default.

> Not putting them in a scope might work for your project, but in general it will
> not, and the workarounds you suggested for it (putting them in separate
> modules) are awkward.

This seems to be the foundation of our disagreement. I can't
understand how you can make this claim, please demonstrate how using
modules is awkward?
It's not awkward to put your code in a module, it's normal... infact,
it's impossible to put D code anywhere other than in a module. All D
code is in a module... so, how can that possibly be considered awkward
or inconvenient?
Organising modules *IS* coding in D, and a user of extern(C++)
wouldn't expect that they are suddenly following a different set of
patterns or rules. They will continue to organise their code in
modules however they usually do, in whatever way best suits their
project or API.

> All (*) the specific examples you've posted about fundamental problems with
> the current scheme have been adequately addressed (bugs were fixed, and
> misunderstandings clarified). Nobody in this thread has been able to
> determine, with an example, what all the other problems you talk about are.

Sure, bugs have been fixed, and I'm certain we can further make this
'work' as the design intends, but that has come at great cost in time
and energy so far; a cost which never needed to be spent, and further
effort is required.
But the point is, making this work as designed doesn't necessarily put
us in a state we're happy with.

Rainer presented a case for confusion; you're making an argument that
the scope is to make it feel kinda like C++ code, but it doesn't
really behave like C++ at all. You can re-open namespaces and add
symbols into existing namespaces until the cows come home in C++, but
in D you end out with multiple definitions of the same named
namespaces in different modules, and then you need to use the full
name (including the module) to disambiguate... which surely makes
plain the reality of the situation, which is that the namespace **is
the module**, not the C++ namespace. Requiring the full module name to
disambiguate leaves the namespace redundant.
I have never, not ever, seen a C++ program where the same namespace
isn't used in basically every source file. After mapping those source
files to D modules, you will have the same namespace defined in every
module, at which point the namespace only acts against it's stated
worth. Further, the namespace almost certainly collides with D's top
level package name.

Other problems like Daniel presented regarding reflection are just
annoying work which doesn't need to happen. Reflection of the kind
that scans scopes for symbols requires new logic which recurses into
C++ namespaces, and no existing reflection code will have support for
that. (Do we actually have __traits which can do that currently? Can
we detect if symbol is a C++ namespace?)
One workaround for that is to alias the symbols from the namespace
into the outer scope, which is just a bunch of pointless work and
noise in the code, but we then want to make the namespace itself
private such that the aliases become the API. Since alias is unable to
make private symbols visible by aliasing them into a public scope,
that leads to effort to create awkward kludges like Daniel presented
to hide the namespace, or the approach I used which involves static
import of cascading modules, and putting all the aliases in the outer
module, doubling the number of files and obscuring the code tree.

> I want to deal with the problems you're having, and find a solution. But
> without examples illustrating them, I am dead in the water and cannot help.

I understand, and I've said I'll find the time to reduce my case and
we can do that work. I just don't have any free time at work right
now, I'll get to this as soon as I can.

Regarding this discussion, as far as I'm concerned, this is a separate
conversation regarding the validity of the features existence. I want
to convince you that it's wrong. Fixing the existing design is a
separate conversation, which I'll reopen as soon as I have more
information for you.
Of course, it would save a lot of effort if you agreed that the design
is wrong, and none of us need to do anything further.