On Fri, Feb 24, 2023 at 4:38 PM Barry Revzin <barry.revzin@gmail.com> wrote:


On Fri, Feb 24, 2023 at 8:38 AM Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Fri, Feb 24, 2023 at 3:12 AM Михаил Найденов via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
>
>
> On Thu, Feb 23, 2023 at 7:31 PM Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
>>
>> On Thu, Feb 23, 2023 at 12:19 PM Михаил Найденов via Std-Proposals
>> <std-proposals@lists.isocpp.org> 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