On Thu, Apr 27, 2023 at 7:20 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thu, Apr 27, 2023 at 12:03 PM Михаил Найденов via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> >
> >
> > On Wed, Apr 26, 2023 at 7:23 AM Andrew Tomazos via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >>
> >> Funnily enough, this exact syntax was considered when pattern matching
> was first discussed. There was a very lengthy discussion about whether to
> use switch or whether to use a new keyword (like inspect), and one of the
> ways that was suggested in the switch case was to use square brackets
> instead of parens to differentiate a pattern switch from a normal switch.
> The support for it was even considerable, but I think the inspect folks won
> out in the end.
> >
> >
> > Interesting, this should have been reflected in the paper so others will
> be aware. In any case, this happened very early in the discussion and
> probably neither the requirements nor the developments were the same back
> then.
> >
> >>
> >>
> >> On Wed, Apr 26, 2023 at 12:38 PM Barry Revzin via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >>>
> >>>
> >>>
> >>> On Mon, Apr 24, 2023 at 2:09 PM Михаил Найденов via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >>>>
> >>>> Hello,
> >>>> Here is a short proposal to re-use `switch` for Pattern Matching.
> >>>
> >>>
> >>> Just so I'm clear. The argument is that introducing a new facility,
> with new semantics, under a new token (whether inspect or match) would be
> bad for teachability.
> >>>
> >
> >>>
> >>> So instead, you're proposing that we reuse an existing token (switch)
> to introduce two very different behaviors (statement vs expression, best
> match vs first match, fallthrough vs exactly one arm, integers vs more
> complex patterns, etc.), but since those different behaviors still need to
> be differentiated by the parser, you're proposing we do so by simply
> switching from parentheses to square brackets around the operand? And
> you're proposing that having 'switch' mean two very different things is
> better for teachability?
> >
> >
> > That's the issue, it is not different semantically or functionally. Sure
> there are nuances, but there are not two different tools that one might
> choose one over the other for a particular reason.
> >
> > We must also consider the negatives by having two similar tools, the
> language already has a problem with that in many places, some of which
> going back to C like the many loops as an example.
> >
> > It seems also that the negatives of extending switch are speculative,
> where the overlap with switch is objective, more or less.
>
> Is it, though? Or is it only "objective" based on your point of view?
>



> Consider `for` vs. `while`. You can argue that it is "objectively
> true" that `for` is just an offshoot of `while`. And yes, any `for`
> loop could be stated as a variant of `while`. So maybe we don't need
> the `for` keyword; it could have just been `while` with some
> specialized parsing stuff in the parentheses.


> But however much these things may be similar in actual function, we
> don't *think* of them that way. When I have a range of indices that
> you want to loop over, I don't even *consider* `while` as an
> alternative solution. The correct answer is `for` because that's what
> it's *for*. The syntax so directly matches its use cases that the more
> generic form just isn't even a consideration.
>

It escapes me what language it was (some of the new ones) that was proud of
itself having only one loop construct, so this point is debatable.
I think it only had `for`.
Anyway, once the tools are there we will always think of them as natural
fit for their specific purpose and all else as a misuse.

While something might technically be implementable as something else,
> you still have to look at the differences, particularly in how we
> conceptualize problems and arrive at a particular solution. Whatever
> functional overlap `switch` might share with `insepct`, it doesn't
> share *conceptual* overlap. When people are having problems that
> pattern-matching solutions would fix, they're not going to
> conceptualize those problems as something that's "like switch".
> They're going to conceptualize them as "pattern-matching problems" and
> react accordingly.
>

If they are "conceptually" different, when will a user reach out for switch
instead of "inspect"?

And why is no other language separating them, incl. Java which has
fallthrough in regular switch, but none when using patterns.


> As such, just like `for`, it deserves its own keyword.
>
> > From the 4 points you made, I honestly can't think of one that is a
> problem in day to day use, with the last two actually being a desired
> positive.
> >
> > Last but not least, the problems of introducing a new keyword are not to
> be underestimated.
>
> Why do you think they have been underestimated?
>
> Also, I do find it a bit ironic. Previously, your proposals around
> pattern matching were all (ostensibly) about making sure that it
> shipped on time. But now, by re-openning a discussion that had
> previously been closed, your suggestion could contribute to a delay.
>
> > inspect (...) is basically guaranteed to be used as a function name in
> some code and will require some parsing ahead. `match` following the value
> will also be hard to do, especially in the case of multiple value (a, b, c,
> d) match.
> >
> > These are problems we create for ourselves out of nowhere, quite
> literally. Better, there is a real reason for that, not just worries.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Няма
вирусиwww.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>