On Tue, Apr 14, 2009 at 9:21 AM, <aschwarz1...@verizon.net> wrote: > > 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'.
I believe that most developers manage to understand the message sufficiently without needing (or caring) to know exactly what a "primary-expression" is -- it's clearly some kind of expression, and they already know what expressions are. The additional information provided by saying "primary-expression" is useful to those who do care about it. (And will motivate a few to become interested in the more precise terminology, maybe.) > 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. Being consistent with the terminology used by the C++ Standard is one of the best ways to protect against changing terminology. The terminology in the standard does evolve, but generally very, very slowly. > 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'm fairly sure that most g++ implementors are very happy when they can, with reasonable confidence, suggest how to fix a problem. The difficulty is in doing so. The correct fix is usually not obvious based only on information available to the compiler, though in various special cases it may be. There are often many ways to eliminate an error, one of more or which might have the correct semantics for a given program. Giving recommendations for how to *fix* the problem can be counterproductive -- many programmers will happily do the first thing they think of to make the warning/error go away, just as when they blindly add casts to eliminate diagnostics about type errors. Providing diagnostics that are simplistic is counterproductive. I certainly agree that there is a lot of room for improvement in g++'s diagnostics. It's not a glamorous project, and it's far from easy, but it would be valuable. There may also be other ways to help: once each diagnostic has a unique identifier, online documentation can offer further advice on how to resolve issues, for example. -- James
