On 10/05/2024 16:04, Peter Dimov via Boost wrote:
There is a way to specify things (from the start) which makes API evolution possible, and it's to add a version number to the interface:
You're now getting into that "broken promises to do something about ABI which would allow us to avoid standardising virtual functions" which I mentioned earlier. Your ideas are a good start, but TBH the work some of us did three years ago are better. Myself, Ben Craig and a few others did some work on seamless versioning of vtables in a non-breaking way that would solve the ABI evolution problem for vptr based objects. I vaguely remember a clever hack to fix RTTI sucking so badly most of the time too, without breaking backwards compatibility. The charitable interpretation of what happened next is that covid occurred, and it got forgotten/the boil went out of it, and then other WG21 stuff happened and then other priorities appeared and it got dropped. The non-charitable interpretation of what happened next is it was realised that this would have to get through EWG, and just about everybody thought they'd rather hammer nails through their fingers than endure that. So it died.
There's actually a way in which we can evolve std::error_category, as it stands today, and it's to derive error_category2 from it, and then use
{ if( auto p = dynamic_cast
(cat_) ) { // use virtual functions from error_category2 } else { // don't } } There's nothing wrong with that _in principle_, but in practice dynamic_cast is abysmally slow (without a good reason, arguably).
Yes you're on a similar track to what we were on. In my contribution to the work I intentionally copied what Microsoft COM does to evolve its vtable based APIs (which are deliberately compatible with MSVC's vtable format) as that is clearly the established precedent, and standards is supposed to standardise existing practice. But just thinking about presenting that at EWG, and the completely stupid FUD comments you'd have to endure from certain members of that working group just because this stuff is COM and/or Microsoft ... and then the demands to "prove your proposal" by forking a production compiler ... and then enduring sermons from those who think they know all about COM and their alternative design they dreamt up yesterday is clearly much better than thirty years of proven track record ... well I wasn't willing, and neither was anybody else. So unfortunately I don't think anything will change here until the processes WG21 uses changes. To make myself very clear here: if it's established existing practice, it should be automatically greenlit and it should be very, very, VERY hard to stop it no matter what the arguments against. There should be a very strong presumption in favour of standardisation of existing practice without redesign by committee, emphasising the "without redesign by committee" part. Niall