On Fri, Feb 24, 2023 at 8:38 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Fri, Feb 24, 2023 at 3:12 AM Михаил Найденов via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> >
> > 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.
>
> Your statement is that the scope of the feature is why it is being
> delayed (and therefore a smaller scoped feature would be faster to
> standardize). The fact that it was delayed is *not* evidence of *why*
> it was delayed.
>
> > 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.
>
> Why do you think that such "arguments" are the problem, if they are
> even happening at all?
>

They are indeed not.

Here's the thing, this paper isn't very useful. It's proposing six things
as "high priority", but apparently nothing else is even medium or low
priority?

But also none of those "nothing else"s is even listed anywhere. It's not
clear what it is that you're attempting to move out of scope. Nor does it
even argue why whatever those "nothing else"s are what is the real problem
with pattern matching - and that thus removing those from scope would make
it easier to adopt pattern matching.

And then the paper says things like:

Further, we should make an effort to have bindings work in tandem with
> other patterns, not just as the sole entity (the “Identifier pattern” in
> P1371). What is more, we will often need to bind at multiple levels, inside
> a recursive pattern structure.
>

Which... what, are you suggesting that P1371 doesn't already support this?
That paper pretty clearly defines all of its compound patterns to
recursively decompose into other patterns.

Or:

This paper advocates no customization for the initial release, outside of
> what is already available in the language
>

Well, P1371 definitely needs to define at least two points of
customization: how "type switch" works (what P1371 calls the alternative
pattern) and how "dereference" works. The latter is probably the easy
answer of if (x) and then *x, but the former is not so easy - especially
when tied into the question of exhaustiveness.

What Pattern Matching really needs right now is a concerted effort to find
solutions to th`e