On Fri, Feb 24, 2023 at 4:38 PM Barry Revzin <barry.revzin_at_[hidden]> wrote:

>
>
> 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
>

My bad, my daughter decided to hit send on my keyboard a bit early.

What Pattern Matching really needs right now is a concerted effort to find
solutions to the outstanding issues that are at least satisfactory and an
implementation. The P2688 design has a really solid foundation - just need
to fill in the details. I just don't think filling in those details
requires removing things from the design that aren't really problematic?
Just consumes more time.

Barry