The issues grow ever more complex. Suppose that we're dealing with macro's, some similarly named, and there's a typo. Suppose several layers of template expansion are involved and nested deep within one there is some error. Suppose, suppose ... .
The motivation is not to expand the problem domain to the point were even stating the problem is a problem, but to creep up carefully and gradually on some consensus option as to what to do and then to go forward. All the points made are valid. At a certain time either the diagnostic message can not perceive nor report on the original cause of error, or the report is convoluted enough to be unreadable by all but the most diligent. Let me address some general principles, which, of course, are both mine and may be wrong. 1: The purpose of compiler diagnostics is to present faults to a user in the most economic way possible. 2: The presentation should be a pointed as possible as to the detected fault. 3: The user should be required to understand as little as possible in order to understand the faulting message. The details of specific messaging are not as important as the guidelines. What I have seen in this thread and in a companion thread, messages, are these viewpoints. 1: The user should have some minimal capability to understand the diagnostic messages as they are now. 2: The user is being overwhelmed with information and has difficulty sifting through it. 3: The messages show the fix but not the problem. Clearly I am biased to 2: and 3:. But let me turn to 1; for a moment. In order to develop software in most languages, C++ being only one, it is not necessary to read nor understand the syntax equations for the language. The notion that developers should be compelled to acquire a knowledge of syntax equations won't work in practice. There is no authority to compell this knowledge nor to deny employment (or hobby work) for someone who doesn't have it. It might be nice but ... . So we are left with compiler users with minimal or none of the assumed pre-requisite knowledge. The notion that these unknowledgeable users should be abandoned in provided diagnostic messages eventually translates into the compiler being abandoned by the users. In the small, probably fine. In the large I would think it unacceptable. And there are competitive compilers. Some with better messaging and better messaging resources at the very point where g++ is weakest. You might argue that they are 'better in what way?', but I think the real argument is in what ways can these other products be a model for g++ to improve itself. Unless the notion is that g++ needs no improvement. A reasoned attitude (I think) is to address each item without prejudice and see if there is some common ground, and then to proceed to see what is possible in general and what edge cases can't be simply solved. I think that there is a way to creep upon a general consensus which may not give everyone everything, but will give most something. And I believe the solution is not a 'camel by committee' but a more useable product. art
