extern(C++, ns)

Manu via Digitalmars-d digitalmars-d at puremagic.com
Thu Jan 7 21:14:26 PST 2016


On 8 January 2016 at 03:02, Carl Sturtivant via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Thursday, 7 January 2016 at 14:03:25 UTC, Marc Schütz wrote:
>>
>> On Wednesday, 6 January 2016 at 17:55:01 UTC, Walter Bright wrote:
>>>
>>> Found and fixed another fwd ref problem with circular imports:
>>>
>>>   https://github.com/D-Programming-Language/dmd/pull/5333
>>>
>>> This one had nothing to do with C++ namespaces; it showed up for structs
>>> and classes, too. This implies that the current design is sound, and a
>>> redesign is not necessarily desirable.
>>
>>
>> By reading Manu's post, I was under the impression that it was actually
>> impossible to use the C++ symbol _without_ the full namespace path, like
>> with static imports. I should have checked this, because it turns out this
>> isn't true at all. I agree then that the current design is mostly ok,
>> especially with your bug fixes.
>
>
> I should have noticed this too; so in fact the current design can be used
> ignoring the scope modeling the C++ namespace. If the details of using such
> an external name in that fashion are identical to any other name at module
> scope in every context, then I therefore concede that the design is OK,
> because it may be treated as the alternative suggested in various ways in
> this thread by simply ignoring the new scope by not using its name.

Again, this is looking at the simple case. The details and more
complex scenarios start to reveal problems.

If the same C++ namespace is present in multiple modules, that is,
x.ns and y.ns, you want to 'import x, y;', the symbols from x and y
are imported into the local module scope, but now you have a name
conflict on 'ns'. Does the imported 'ns' refer to x.ns or y.ns? This
case is everywhere, since every module with extern(C++, ns) will have
the same top-level symbol.

We considered a case where you do import renaming, for instance:
import x : newname = symbol;
This no longer works, we would need a further 'enhancement' such that:
import x : newnane = ns.symbol;  is a valid statement.

I had another case where a mixin template would refer to some symbol,
the name resolution breaks down when multiple imports define the same
C++ namespace (which they basically all do), and it gave errors that
it was unable to find the function I was referring to, despite the
module that defines it being imported at top-level.

My point remains, the namespace scope introduces a lot of complexity,
we're likely going to have to add further 'features' to make it not
broken and work in all the edge cases, and there's still no good
reason for it to exist at all... how is it that removing a point of
complexity and thus solving a bunch of related problems could not be
better than adding further complexity to try and round off something
that is already a point of needless complexity?

The module system works, it's completely reliable. We want to use it
exactly how it is.
Walter: if you insist that namespace scopes MUST exist for reasons
that make no sense to me no matter how I look at it, then give us an
opt out. It should not require more complex code to undo complexity
and represent something that is, in fact, less complex, ie:

extern(C++, ns) struct Thing {}
alias Thing = ns.Thing;

That is needless complexity, it affects _every single extern(C++)
declaration_ in my program, and I only know to do that because I am an
expert... why would anyone else on my team, a junior for instance,
know to do that? It's just asking for trouble. If I forget that alias,
the errors can be rather unintuitive. They will interrupt me, and I
would have to explain it.

The namespace offers nothing, and introduces problems. We don't want it.



More information about the Digitalmars-d mailing list