On Thu, Jul 11, 2024 at 10:03 AM Thiago Macieira via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
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.

I gather from the discussion of P2025 that in order for it to advance further in EWG, a complete implementation is likely required in at least one compiler. There has not been a revision of the paper for quite some time; although I haven't spoken to Anton about it, I would guess that he simply felt that this task was too complex and gave up, which is what I would have done if I were in his situation. Implementing a core language proposal in a compiler is quite a challenge.

And actually, I think that it simply isn't worth it. What I really want to be able to do is get explicit access to the function's return slot, but also have some safeguards that make it hard for me to accidentally access it before I've constructed it. This will require some kind of syntactic extension to the language.

P2025 seemed like an appealing idea when it was a simple tweak with no major implementation concerns. Now that it has serious implementation concerns, I see no reason not to dream of a more general solution.

As far as I'm concerned, P2025 is dead unless I see evidence to the contrary. Future proposals should simply discuss it and then move on.
 

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



--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


--
Brian Bi