On Sat, May 24, 2025 at 2:42 AM Zhihao Yuan via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Friday, May 23rd, 2025 at 8:18 PM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> >
>
> > > Pattern matching doesn't check either of
> > > these. At a semantic level, patterns are tried
> > > sequentially in from top to bottom, and users
> > > must keep this in mind to write correct code.
> >
>
> >
>
> > Which is often required, especially if we want to support something like
> > regular expression matching or other matching methods that aren't completely
> > disjoint.
> >
>
>
> That's not the point. Sure, from pattern
> matching's point of view, many needs can
> be "required." But `switch` is disjoint
> by construction. Therefore, when comes to
> performance, no matter how users write
> it, it won't be inefficient. And when
> comes to reading and modifying the code,
> users can read each individual flow by
> "jumping" into it - other "cases" do
> not matter in that process.

But... they do matter when reading the code. If you want to understand
what a switch statement can do, you have to read the various `case`.
And that generally happens top-to-bottom. So most users are going to
have to read all of the cases up to the one they're interested in.

Not to mention that, because of default-fallthrough, understanding the
flow of a switch *requires* looking at prior flow. You cannot be sure
that a particular `case` is the only way to reach that code unless you
look for a `break` in the preceding `case`.

You seem extremely fixated on the notion of pattern matching "having
to" test each condition in-order. It seems to me that the "as if" rule
would cover this in cases where the conditions are all
integer-constant expressions (ie: where `switch` could be used). Do
you have any evidence that pattern matching will *necessarily* produce
worse code in cases where `switch` could be used instead?