www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Thread name conflict

reply "John Chapman" <johnch_atms hotmail.com> writes:
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.
May 05 2014
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
May 05 2014
parent Jacob Carlborg <doob me.com> writes:
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
May 05 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
May 05 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
May 05 2014
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
May 05 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
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!();
May 05 2014