Hi all,

I'm a little out of practice with reporting bugs so I just wanted to check I was doing the right things.  First I managed to change my email associated with my account on the bug tracker (old account was old work account that I no longer have access to), yay me!

Next I logged in and looked for a bug report on the same topic... I think issue 463 is closely related though coming from another angle.  What do people here reckon?

Here is my bug test case:

[bug001.d]
import std.random;
void main() { index++; }

Error reported on compile is:
"C:\D\src\tmp\bug001.d: module bug001 std.random.index is private"

Notes:
0 - Obviously this occurs because there is no local 'index' variable. This was a typo in the original code.

1 - There is no line number in the error message.  This occurred inside a small piece of code so it was easy-ish to find, imagine a larger block of code!

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.

Regan

Regan Heath skrev:

> Here is my bug test case:
> 
> [bug001.d]
> import std.random;
> void main() { index++; }
> 
> Error reported on compile is:
> "C:\D\src\tmp\bug001.d: module bug001 std.random.index is private"

[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. Wouldn't it be helpful to be told that a protection attribute prevented the access instead of an unhelpful "undefined identifier"? 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.

More serious is that the following altered program compiles without error:

import std.random;
void main() { std.random.index++; }

/Oskar

Oskar Linde Wrote:
> Regan Heath skrev:
> 
> > Here is my bug test case:
> > 
> > [bug001.d]
> > import std.random;
> > void main() { index++; }
> > 
> > Error reported on compile is:
> > "C:\D\src\tmp\bug001.d: module bug001 std.random.index is private"
> 
> [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. Wouldn't it be helpful to be told that a protection attribute prevented the access instead of an unhelpful "undefined identifier"?

There is that... at the very least it needs a line number in the error as it can be difficult to find otherwise.

> 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.
> 
> More serious is that the following altered program compiles without error:
> 
> import std.random;
> void main() { std.random.index++; }

That's not good.

Regan

On Mon, 25 Jun 2007 16:37:25 +0200, Oskar Linde wrote:

> More serious is that the following altered program compiles without error:
> 
> import std.random;
> void main() { std.random.index++; }

What really annoys me about this oft reported bug is that Walter is still silent as to whether he regards it as a bug or not. At this stage all I'd like is either "No that is not a bug because <whatever>..." or "Yes it is a bug and its on my TODO list".

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
26/06/2007 6:30:56 PM

"Oskar Linde" <oskar.lindeREM@OVEgmail.com> wrote in message
news:f5ojv9$13sj$1@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. 

"Derek Parnell" <derek@nomail.afraid.org> wrote in message news:1uh6rpcdf3j1o.10ejke9tjk8w1$.dlg@40tude.net...
> On Mon, 25 Jun 2007 16:37:25 +0200, Oskar Linde wrote:
>
>> More serious is that the following altered program compiles without error:
>>
>> import std.random;
>> void main() { std.random.index++; }
>
> What really annoys me about this oft reported bug is that Walter is still
> silent as to whether he regards it as a bug or not. At this stage all I'd
> like is either "No that is not a bug because <whatever>..." or "Yes it is a
> bug and its on my TODO list".

What possible excuse is there for thinking this isn't a bug?

Stewart. 

Stewart Gordon skrev:
> "Oskar Linde" <oskar.lindeREM@OVEgmail.com> wrote in message
> news:f5ojv9$13sj$1@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

"Oskar Linde" <oskar.lindeREM@OVEgmail.com> wrote in message news:f5rarh$2a82$1@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. 

On Tue, 26 Jun 2007 12:53:48 +0100, Stewart Gordon wrote:

> "Derek Parnell" <derek@nomail.afraid.org> wrote in message news:1uh6rpcdf3j1o.10ejke9tjk8w1$.dlg@40tude.net...
>> On Mon, 25 Jun 2007 16:37:25 +0200, Oskar Linde wrote:
>>
>>> More serious is that the following altered program compiles without error:
>>>
>>> import std.random;
>>> void main() { std.random.index++; }
>>
>> What really annoys me about this oft reported bug is that Walter is still
>> silent as to whether he regards it as a bug or not. At this stage all I'd
>> like is either "No that is not a bug because <whatever>..." or "Yes it is
>> a
>> bug and its on my TODO list".
> 
> What possible excuse is there for thinking this isn't a bug?

None that I can think of, but I was not trying to second-guess Walter's Theory of Good Programming Practice, because I've done that in the past and discovered that Walter and I have sharply different opinions about that subject. <G>

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

Stewart Gordon schrieb am 2007-06-26:
> "Oskar Linde" <oskar.lindeREM@OVEgmail.com> wrote in message news:f5ojv9$13sj$1@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.

This might be what you expect, but in D "private" is always visable but not accessable outside of the modle it was defined in.

Yes, this behaviour might be unexpected for many but has been so for a long time.

Thomas