On Sat, Feb 25, 2023 at 12:38 AM Barry Revzin via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

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

We are speculating at this point, but the overall discussion has not reached that point to care about bikishadding.
When the time comes, there is great possibility, will have such a discussion, I only wish to move it beyond 26.

But it is not just bikeshedding, this exact topic will require expensive discussions about a customization point.
If we do not provide one what is the value of having this? C++ values its encapsulation, do we really want to encourage using structs in order to use the fancy new PM?
 

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.

This is backwards, I believe. It must be proven something must be added, not the other way around.

Say we have PM in the language, if someone wants a new feature, say extractors, they must prove the need and why this way is the best one to do it. 

There is no reason not to apply this logic here - have a core set now, whatever it might be, finish it, release it, then do the rest in iterations.
I have never said, what will be removed must be buried and never looked at again.
 
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.

There is no "real problem" w/ PM and even if there is, it is probably not in features proposed to postpone. This does not change the fact, postponing features will, by definition, give us more time for "the real problems" and improve delivery. 
 

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.

Not really, especially in its current iteration as it does not have a bind pattern (only a workaround via `at`), but say it does (as per P2688) and we resurrect `let`.
At no point any of currently active proposals directly address (with an example) binding at multiple levels like binding both the optional and the value:
given optional  ox;
let ?x will bind the value, how do I bind the optional as well? I suppose, it would be let ox = let ?x, but again it is not stated clearly. 
 


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. 

I guess I mean "explicit customization points''. Indeed the deref can be defined implicitly, but so does typeswitch if we restrain ourselves a bit and postpone the exsotic versions of the "alternative pattern" like enum-to-type matching.
The core type switching will be class hierarchies, variant-like, any-like, which is plenty for an initial release, and should not require explicit opt-in and user-side adjusting to work with PM.
 



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.

Agreed. Not having a backlog of "nice-to-have"-s, which also have the potential to turn into time syncs is a good way to both focus on the real issues and deliver on time. 
 
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.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals