On Thursday 11 July 2024 06:54:03 GMT-7 Frederick Virchanza Gotham via Std-
Proposals wrote:
> On Thu, Jul 11, 2024 at 2:42 PM Thiago Macieira wrote
>
> > If we can't get one into the C++26 standard in time, why would we get
> > something else in the same line in time? Especially if there's already a
> > paper that ostensibly is a better and wider solution?
>
> The superior paper is suffering a lack of progress. Not enough talk
> about it, not enough enthusiasm and drive to pull it into the
> Standard.
>
> My inferior paper is much much much simpler and doesn't require a
> change to the core language. Not much thinking required to get it into
> the Standard.

So if the car brakes don't work, we ask the mechanic to fix the horn?

> It's a lot more likely that a simple paper will make it into C++26,
> than a much much much more complicated paper.

The problem is that there is a better paper in the pipeline. Either it's
withdrawn or explicitly rejected, because until then I don't see a path to
adding a short-term, stop-gap solution. It's not like we have a pressing need:
C++ has existed for 30 years without this, so we can wait a few more years to
get the right solution.

Either that, or your paper argues that it's a replacement for the sufficiently
many use-cases that it makes the other one unnecessary.

That's different from when we added things when we didn't know better, like
std::is_constant_evaluated() vs if consteval. Experience can tell us that what
we thought was a solution wasn't, or not completely.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering