Re: Thread name conflict
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
Re: Thread name conflict
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
Re: Thread name conflict
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.
Re: Thread name conflict
On Mon, 05 May 2014 13:11:29 + 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
Re: Thread name conflict
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!();
Re: Thread name conflict
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
