C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Proposal to limit the scope of Pattern Matching for a '26 release

From: Михаил Найденов <mihailnajdenov_at_[hidden]>
Date: Fri, 24 Feb 2023 10:12:26 +0200
On Thu, Feb 23, 2023 at 7:31 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thu, Feb 23, 2023 at 12:19 PM Михаил Найденов via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > One last revision. I have decided "not to bother", but after the last
> meeting PM is now "conservative C++29" target, which was added as a point
> in the motivation.
> > This is I think the realistic-to-optimistic target, mainly because there
> are 2 completely different proposals in flight, both of which doing too
> much for an initial release (in my opinion obviously).
> > We have to define some scope and get something finally.
>
>

> You keep saying this, but you provide no evidence for it.

The evidence is that from C++23, now we brace for C+29.
Besides, though there was progress, it is "nullified" by having a new
proposal.


> Why do you
> think scope is the problem here?

Why do you think your proposal would
> be adopted faster?
>

Limiting the scope is an easy way to reduce the amount of time needed.

We will not have to argue should we have
[member: 5] or [.member 5] or [.member: 5] for deconstructing w/ designators
and then what the customization point would be, should we have any,
if we don't have deconstructing w/ designators for the initial release.

As I said, I have decided to literally save my time and effort not
bothering, but it is so glaring we are walking into another
concepts/contracts/modules/coroutines/executors design loops, that at least
I had to propose a limited scope in hope we can avoid another rabbit hole.


> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2023-02-24 08:12:40