3 ms·
> We could just deprecate std::regex and propose std::regex2, but the moment that proposal comes out everyone gets annoyed about the name and “why can’t we just
by phendrenad2 5y ago
> We could just deprecate std::regex and propose std::regex2, but the moment that proposal comes out everyone gets annoyed about the name and “why can’t we just fix regex?!” and then the ABI people pipe up and around and around the circle goes
This is the core of the issue. I continue to maintain that these issues are not insurmountable, bit we have a "people problem" that makes them effectively insurmountable. There are too many people with deep expertise in one area of C++ (compiler implementation, language design, etc.), who don't have a big-picture view, yet will let their opinions known as though they know everything. And it's not just C++, all open-source languages have this problem. Design-by-committee never did anyone any favors. It's precisely WHY we keep getting half-assed implementations like regex and nested functions approved in the standard library pr GCC extension, and it's WHY no one is ever permitted to fix them.
The only solution is for people to abandon their egos, admit that someone may know more than them (choc et horreur!), and try to do what's right for the users.
- int_19h 5y agoThere's nothing half-assed about gcc nested functions - they work exactly as they should. The problem is that the feature was implemented back when runtime constraints were very different - in particular, there were no limits on dynamic codegen, not even on the stack. Using thunks for callbacks was a common technique back then - and why not, given the perf benefits? On top of that, ironically, it was also the only way pointers to nested functions could be transparently compatible with the C ABI. So I don't think your criticism is valid in this case. It's more a general problem with all language extensions, and how they interplay with language evolution.