Re: What is this "Beman Project Development"?

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2024-05-10 15:38:25

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<error_category2 const*>(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