On Monday, 5 May 2014 at 12:48:11 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Mon, 05 May 2014 15:55:13 +0400
Dmitry Olshansky via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
Why the heck should internal symbols conflict with public from
other
modules? No idea.
Because no one has been able to convince Walter that it's a bad
idea for
private symbols to be visible. Instead, we've kept the C++
rules for that, and
they interact very badly with module-level symbols - something
that C++
doesn't have to worry about.
As far as I know Walter does not object changes here anymore. It
is only matter of agreeing on final design and implementing.
Unfortunately, as I understand it, fixing it isn't quite as
straightforward as
making private symbols invisible. IIRC, Martin Nowak had a good
example as to
why as well as a way to fix the problem, but unfortunately, I
can't remember
the details now.
I remember disagreeing with Martin about handling protection
checks from template instances. Those are semantically verified
at declaration point but actual instance may legitimately need
access to private symbols of instantiating module (think template
mixins). Probably there were other corner cases but I can't
remember those I have not been arguing about :)
Anyway, DIP22 is on agenda for DMD 2.067 so this topic is going
to be back to hot state pretty soon.
