Thread name conflict

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Mon May 5 06:32:55 PDT 2014


On Mon, 05 May 2014 13:11:29 +0000
Dicebot via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

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

Well, that's good to hear.

> > 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 :)

IIRC, it had something to do with member functions, but I'd have to go digging
through the newsgroup archives for the details. In general though, I think
that private symbols should be ignored by everything outside of the module
unless we have a very good reason to do otherwise.  Maybe they should still be
visible for the purposes of reflection or some other case where seeing the
symbols would be useful, but they should never conflict with anything outside
of the module without a really good reason.

> Anyway, DIP22 is on agenda for DMD 2.067 so this topic is going
> to be back to hot state pretty soon.

It's long passed time that we got this sorted out.

- Jonathan M Davis


More information about the Digitalmars-d mailing list