2009/4/14 Arthur Schwarz <aschwarz1...@verizon.net>: > > 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. >
Then, you should mention what kind of error messages are given by other compilers (or C++ front-ends). In my experience that helps a lot to get your point across. Then, maintainers (who are the ones that at the end decide what is accepted and what is not) can assess if the alternative message is better or worse. But to do that, maintainers will probably prefer a patch implementing the message. GCC diagnostics need a lot of improvement. There are many open PRs that are just waiting for someone to work on them. Sometimes someone works on one of them, produces a patch, the patch gets accepted, the PR gets fixed and GCC diagnostics are slightly improved. > 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. And yet, you are arguing about "gcc messaging" in general. Without any working knowledge of gcc capabilities or internals is just a pointless exercise. You seem to assume that "someone" will implement your proposals. That may happen, but in my experience, it is very, very unlikely. What is more likely is that (a) some people will not understand your verbal description of an implementation, (b) some people are happy with things as they are and will resist change, (c) some people will agree with you and do nothing else. In any case, the result would be that nothing is done. > 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. > You do not need any consensus. You just need to put forward a patch that implements your proposal and give enough reasons to the relevant maintainers to accept your patch. And you'll need a lot of patience and be willing to compromise. Otherwise, this thread has a 99% chance of being completely futile (Reporting precise, well-argued and detailed PRs will lower the chances). Cheers, Manuel.
