Error message for a private identifier in an imported module (was: Bug tracker best practices)

Stewart Gordon smjg_1998 at yahoo.com
Tue Jun 26 03:46:43 PDT 2007


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

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.  Would you expect an error to this effect on 
using a name that matches that of a local variable in some obscure function?

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

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

> 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

Stewart. 




More information about the Digitalmars-d mailing list