On Saturday, July 20, 2024, Tiago Freire wrote:

>
> I strongly disagree with your perception of the poll.
>
> I think Anton's paper is much more solid, it doesn't introduce any new
> syntax or functions. It achieves all of the goals by just providing
> guarantees on what had previously been optional and inconsistent.
>
> While this seems a hacky adhoc solution, makes writing code much more
> convoluted, and requires an unstated magic solution (a subset of Anton's
> solution) in order to even be implementable.
>
> I rather wait for C++29 than to have this, even if I have to champion it
> myself.
> Anton's paper actually solves the problem at the root cause and is the
> simplest solution you could possibly have (which in my book is always
> better).
>
> You may disagree with my observation, but I disagree with yours, and I'm
> of the felling that I'm not the only one sharing this opinion.
>



P3357 can have two separate marketing campaigns.

For the people who really want P2025, I'm happy to market P3357 as a stop
gap which will become deprecated at some point in the future.

For the people who don't want P2025, I'm happy to market P3357 as an
alternative to P2025.

Tiago, the lack of progress on P2025 is what spurred me to get P3357 going.
Unless you plan to hit the Turbo button on P2025 and succeed in getting the
polls to tilt in its favour, I think P3357 will be helpful as a stop gap.

Remember, we should be about progress, not perfection. Since P3357 doesn't
involve a core language change, ripping it out in the future to replace it
with something superior won't be a big deal.