• John Chapman (7/7) May 05 2014 Importing both core.thread and std.regex results in a conflict as
• Dmitry Olshansky (9/15) May 05 2014 Neat. I couldn't make a better case for D to finally fix visibility of
• Jonathan M Davis via Digitalmars-d (16/18) May 05 2014 Because no one has been able to convince Walter that it's a bad idea for
• Dicebot (12/32) May 05 2014 As far as I know Walter does not object changes here anymore. It
• Jonathan M Davis via Digitalmars-d (12/45) May 05 2014 Well, that's good to hear.
• Dicebot (12/25) May 05 2014 This works now and must continue to work I believe:
• Jacob Carlborg (4/7) May 05 2014 Yes, it's useful for .tupleof to access private members.

"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 

example allows it.

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


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

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

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

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

"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!();

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