Importing both core.thread and std.regex results in a conflict as both define a Thread type.

Perhaps the regex module's author assumed there'd be no clash since it's a template - Thread(DataIndex). Should I file a bug suggesting a name change? Or maybe D ought to allow both parameterised and normal types to have the same name - C# for example allows it.

05-May-2014 12:03, John Chapman пишет:
> Importing both core.thread and std.regex results in a conflict as both
> define a Thread type.
>
> Perhaps the regex module's author assumed there'd be no clash since it's
> a template - Thread(DataIndex). Should I file a bug suggesting a name
> change? Or maybe D ought to allow both parameterised and normal types to
> have the same name - C# for example allows it.

Neat. I couldn't make a better case for D to finally fix visibility of private symbols.

Why the heck should internal symbols conflict with public from other modules? No idea.

Seems like turning std.regex into package will fix this one though, as I could put private things into std.regex.dont_touch_it_pretty_please.

-- 
Dmitry Olshansky

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.

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. Regardless, I think that most of us agree that the fact that private symbols conflict with those from other modules is highly broken. And it makes it _very_ easy to break code by making any changes to a module's implementation. The question is how to convince Walter. It'll probably require that someone just go ahead and implement it and then argue about a concrete implementation rather than arguing about the idea.

- Jonathan M Davis

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.

On Mon, 05 May 2014 13:11:29 +0000
Dicebot via Digitalmars-d <digitalmars-d@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@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

On Monday, 5 May 2014 at 13:33:13 UTC, Jonathan M Davis via Digitalmars-d wrote:
> 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.

This works now and must continue to work I believe:

// a.d;

mixin template TMPL()
{
    void foo() { z = 42; }
}

// b.d
import a;

private int z;

mixin TMPL!();

On 2014-05-05 15:32, Jonathan M Davis via Digitalmars-d wrote:

> Maybe they should still be
> visible for the purposes of reflection or some other case where seeing the
> symbols would be useful

Yes, it's useful for .tupleof to access private members.

-- 
/Jacob Carlborg