Well, no, the issue is that the compiler writers refuse to acknowledge the these obviously incorrect things are incorrect in the first place and tend to blame users for tripping over compiler bugs. If it were just that they didn't know how to fix said bugs, that would be a qualitatively different and much less severe problem.
Because you'll spend a lot of time chasing down bugs that are actually issues in the compiler. Unless you're trying to vet the compiler itself, this won't improve your software but cost you a lot of effort.
The article perfectly explains why the author wants you to break the compiler. It's so it can be improved and to do that user feedback (by breaking the compiler) is needed.
The bug isn't in the language, you just disagree with some of the goals. It was designed for the compiler to be small and easy to write, with data types and operations that map directly to operations that most CPUs can perform.
I suppose this is one of those things where people’s experiences vary widely, but FWIW after 20 years of writing C/C++, I can count the number of times this has bitten me on one finger. And even then, I still think it was more likely just an optimizer bug in the god-awful compiler.
are you sure the compiler is smart enough to do that? I think we frequently assume compilers are smarter than they really are because we don't fully understand them anymore... but in practice I find they often do very dumb things.
This does not address the real-world case where built-ins will not compile in some valid code contexts. It is not "better" to do something that literally doesn't work. No one is doing this for fun, it is working around a well-known limitation in current compilers.
Because it is an unfortunate limitation on built-ins that reduces their utility, fixing this is on the roadmap for most popular compilers.
reply