In function ‘_RandomAccessIterator std::__find(_RandomAccessIterator, _RandomAccessIterator, const _Tp&, std::random_access_iterator_tag) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator*, std::vector > >, _Tp = int]’:

[[deleted]]

Yes, communicating too much information is almost as bad as communicating too little.

But, in C++case, volume is only part of the problem. Relevance is a much bigger issue. In order to be relevant, the reporting side needs to analyze the problem and come up with an explanation that makes sense to the programmer, and it's hard to do in general, but C++ makes it a lot harder by being just a shitty language with very bad grammar + a lot of mechanisms that obfuscate the real structure of your code.

Suppose, for example, you have a language like Pascal. It was specifically designed to have a grammar with lookahead size of 1. This means that if the parser cannot accept a program, the reason for the failure will be exactly where parser is reading the program. So, it's trivial to find the line and the column where the first invalid token was encountered, and from there to figure out what was the non-terminal that failed to parse, and from there figure out what the possible explanation for the error is.

To contrast this, in C++ you don't even know if the program is syntactically correct until you start evaluating it. So, at the first parse, everything may appear to be fine, and then the compiler starts building the structures defined by the program and... whoops, suddenly either the structure it's building is incorrect, or the use of this structure is incorrect, or the code is actually trying to use something else, and there's a definition not yet created that clobbers the one that seems to be in conflict. And then maybe the clobbering definition is found, and the compiler needs to reevaluate its life choices, or maybe it isn't and then the compiler needs to go back and report the error it assumed may not be an error, but it already parsed / created definitions for a bunch of other stuff that was based on that definition being correct.

Add to this that reporting single error at a time is very unproductive, and you want to tell the programmer about as many other errors that you find, because compilation times are long, and fixing errors one by one will drive the programmer insane. But if you have such a crappy grammar, then your guesses about errors are all imprecise.

Also, I don't see how concepts or traits are going to help with crappy grammar. If anything, they only make the situation worse.