Error message for a private identifier in an imported module

[Oskar Linde]

Stewart Gordon skrev:
> "Oskar Linde" <oskar.lindeREM at OVEgmail.com> wrote in message
> news:f5ojv9$13sj$1 at digitalmars.com...
> <snip>
>>> 2 - std.random.index is private so it's not likely I am actually trying
>>> to modify it.  I think I should get the error:
>>> "C:\D\src\tmp\bug001.d(2): Error: undefined identifier index"
>>> instead.
>>
>> Compiler error messages are a tricky business. What if you were actually
>> trying to refer to a private identifier in another module.
> 
> Debatable indeed.  But my thought is: if it's another module, why should 
> you be aware that this private identifier exists?

Maybe you are developing both modules in parallel.

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


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

>> I believe the best (only?) approach to compiler diagnostic messages is 
>> for
>> the compiler to tell, as descriptively as possible and from its own
>> perspective, why something failed. Not trying to second-guess the users
>> intentions.
> 
> AISI, what the compiler is actually doing is third-guessing the user's 
> intention.
> 
> But you could ask what's best.  There are three distinct possibilities:
> (a) it isn't in any imported module
> (b) it's in one imported module
> (c) something private by that name exists in more than one imported module
> 
> If (a), then there's obviously only one option.
> If (b), there's a slim chance that the coder misread the code of an 
> imported module by missing the word "private", but how likely is this?  
> So maybe it makes a bit of sense to point this out, just in case.  But 
> it can also be confusing.

This is the case discussed above and the optimal message may be 
something along the lines of "undefined identifier 'index', however a 
private identifier is matched in module std.random".

> If (c), what should happen?  It doesn't make sense to single out one of 
> the modules to mention it in, but to list them all would clutter the 
> error message.  Nor does it make sense to complain that the identifiers 
> conflict if they're private.

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.

>> More serious is that the following altered program compiles without 
>> error:
>>
>> import std.random;
>> void main() { std.random.index++; }
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=257

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

This one means that adding a private function to a module may break code 
in other modules.

/Oskar