Re: messaging

[aschwarz1309@verizon.net]

Thanks Kai. I do have what I hope is a more specific subjective reason for saying that I think the existing diagnostics should be changed. Fundamentally, what is provided in the messaging is not an indication of what is wrong, but an indication of what is required to repair the fault. My objections then become:
1: As an old man full of wisdom, most developers can't distinguish a
   'primary-expression' from a washing machine. Further, to determine
   what correction might be needed most users would have to research
   the C++ standard (or other standardized document supported by the
   g++ development community) to find out exactly what constitutes a
   'primary-expression'. 
2: It puts an obligation on the g++ development community to ensure
   that the messaging is consistent with documentation and that if the 
   term 'primary-expression' changes then g++ will change the messaging
   to conform to the new term. 
3: The cause of the error is more specific than it's solution. The cause
   of the fault is the user (in this case me) provided something that
   was wrong. It wasn't the lack of a 'primary-expression' but the
   existence of the illegal constructs. My conjecture is that if the
   message says "you did this wrong" then the user would have an easy
   time of finding a fix.

I don't argue with the details of my wording. My intent is not to show that I am a better wordsmith but that the existing diagnostic messages are not specific enough. From Item 1: above, in order for the average user to fix the error the user must research the terms used, then compare the syntax given with the actual fault, and then fix the error. If the message say "this is the fault", the research goes the way of the woolly-mammoth.

The paradigm is that the message should provide the minimum amount of information required to identify the syntax/semantics which caused the failure.

art

--- On Mon, 4/13/09, Kai Henningsen <kai.extern@googlemail.com> wrote:

> From: Kai Henningsen <kai.extern@googlemail.com>
> Subject: Re: messaging
> To: "Arthur Schwarz" <aschwarz1309@verizon.net>
> Cc: gcc@gcc.gnu.org
> Date: Monday, April 13, 2009, 11:12 PM
> Arthur Schwarz schrieb:
> > In the following code fragment:
> > 
> > # include <ios>
> > # include <fstream>
> > # include <istream>
> > 
> > using namespace std;
> > void CommandLine(int argc, char** argv);
> > int main(int argc, char** argv) {
> >    CommandLine(argc, argv[]);
> >    ifstream x.open(argv[1], ios:in);
> >    ofstream y.open(argv[1], ios::in);
> >       return 0;
> > };
> > 
> > g++-4 messaging is:
> >>> g++-4 x.cpp
> > x.cpp: In function 'int main(int, char**)':
> > x.cpp:8: error: expected primary-expression before ']'
> token
> > x.cpp:10: error: expected primary-expression before
> ':' token
> > 
> > A recommendation and reason for change is:
> > 1: x.cpp:8 error: illegal to pass an array without
> subscript value as an    argument
> >    The given message is accurate but
> non-expressive of the reason
> >    for failure.
> 
> Actually, in this case I'd say that the original message is
> perfectly fine, and your suggestion is rather confusing.
> However, what one could say here is something like "[] is
> only allowed in declarations".
> 
> 
> > 3: cpp:10 error: illegal scope resolution operator
> ':'
> >    From memory, there are three uses of ':'
> in C++
> >    ':'   label terminator,
> <label>:
> >    ':'   case in a switch
> statement, case <value>:
> >    ':'   scope resolution
> operator, "::"
> >    The given diagnostic message is
> deceptive. 
> 
> Could perhaps say "':' is not a scope resolution operator",
> unless someone comes up with a use case where it is ...
>