On Thu, Jul 11, 2024 at 10:03 AM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*