Error message for a private identifier in an imported module

[Stewart Gordon]

"Oskar Linde" <oskar.lindeREM at OVEgmail.com> wrote in message 
news:f5rarh$2a82$1 at digitalmars.com...
> Stewart Gordon skrev:
<snip>
>> If an identifier is declared as private, it is strictly part of the 
>> module's internal workings.  Its creator never intended it to be _seen_ 
>> outside of the module, let alone accessed.
>
> Unless the creator and the one requesting access are the same person. Or 
> maybe a module's api changed making something that used to be public 
> private. The current error message is certainly helpful in those cases (if 
> it only contained line numbers of course).

Yes, you have a point there.  But if it's an API change, it probably ought 
to start off deprecated.  It's a shame that D doesn't support 'deprecatedly 
public', though you should be able to improvise with an alias.

>>> Wouldn't it be helpful to be told that a protection attribute prevented
>>> the access instead of an unhelpful "undefined identifier"?
>>
>> Instead?  If it didn't prevent the access, you'd be able to tinker 
>> arbitrarily with a module's internal workings.
>
> Huh? You must have misunderstood me. The error message text doesn't 
> prevent or allow anything. Instead refers to an hypothetical alternative 
> wording.

Oops....

<snip>
> You have a point, although I don't see much wrong in listing all 
> conflicting symbols. In fact, I remember being confused once when typing 
> something like:
>
> pow(1.0,-1);
>
> expecting it to call the (real, int) overload and being told:
>
> function std.math.pow called with argument types:
>         (double,int)
> matches both:
>         std.math.pow(real,uint)
> and:
>         std.math.pow(real,real)
>
> But the overload I wanted (real, int) isn't even mentioned. IMO, the best 
> behavior would be for the compiler to list all conflicting overloads.

Yes, that's a case where we do want it to list them all.

<snip>
> Another serious (and confusing) one:
>
> m1.d:
> void foo(int x) {}
>
> m2.d:
> private foo(double x) {}
>
> main.d:
> import m1,m2;
> void main() { foo(1); }
>
> Yields:
>
> main.d:2: Error: m1.foo at m1.d:1 conflicts with m2.foo at m2.d:1
<snip>

That's one I found reported, albeit in relation to a particular identifier 
in Phobos.  I changed the summary line to be more generic:
http://d.puremagic.com/issues/show_bug.cgi?id=1238

Stewart.