Comment by vlovich123
12 hours ago
This has appeared multiple times over the years as “compiler improves c++ errors” and is even the reason given as motivating things like concepts. Sure it keeps improving but the errors don’t seem to actually get smaller. The problem is inherent to templates - c++ got it wrong by having templates start weakly typed and it has no mechanisms to correct it in the language - concepts helped but didn’t definitively fix it and also are a serious level of complexity (ie for writing and defining concepts) - it just shifted the burden one level but ultimately the mess is still there.
After more than 20 years in c++, I gave up that the situation will ever really be fixed vs constantly being made better at the margins, but not as fast as new ideas get added to the language.
You're not wrong there. The late stage (compilation wise) of template instantiation doesn't help either, as so much context has been built up. The art of debugging C++ compiler output is knowing which 90% to ignore. If you read it all you'll simply go mad.
Concepts at least tells you which criteria you didn't satisfy (as long as the concept is correct...), which - admittedly - feels like putting a bandaid on bullet wound.
Even without having concepts, a cpp compiler could conceivably detect at definition time that the template is acting as a generics declaration only, and treat it specially as if it was a "late-bound concept". That would potentially help with codegen, but it would certainly help with making compile errors better. I find it is hard to convince compiler engineers to divorce themselves from what the language semantics are and what the compiler does. As long as the user visible behavior is the same, you can internally handle things differently for conceptually this same feature.
Rust has the same problem as templates with macros. We haven't had a strong need to customize the macrosl evaluation much, but I could very much see us special casing macros that are function like, or have macro arms that can only be a handful of things in order treat them different so diagnostics get better. The only thing that comes to mind thar we do today, is that when a macro call falls through (no macro arm matches), we retry it adding commas in between expressions to see if it was just a typo.
Concepts could be much better, but first we only got the light version, and secondly the effort hasn't been there regarding improving the error messages.
Also, so far I would say they haven't been getting people rushing out to use them anyway, as C++20 is still too new for many projects.
Even GCC only now changed to C++20 as default mode.
Concepts have been disappointing for me: what they tell you is still buried in 1000 lines of errors.
Concepts support (like traits I'm Rust) is necessary for good diagnostics, but not sufficient. It gives you the architecture and metadata that you require to infer what the user wants, but a lot of additional analysis on the decision chain that was followed in order to figure out what is relevant and what isn't.
1 reply →
concepts have been excellent for me for overload resolution in complex template code (good riddance SFINAE) and for documentation.
To improve error messages, not so much.
The problem isn't C++, the problem is that the meagre resources those teams have available, rather spend their time catching up to ISO C and ISO C++, than improving error messages.
Hence why SARIF has seen big adoption, as they hope that by exposing that , there are others ways to have others have tools that process SARIF.