On Sat, Feb 25, 2023 at 12:38 AM Barry Revzin via Std-Proposals <
std-proposals_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>