On Fri, May 23, 2025 at 7:53 PM Zhihao Yuan via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> On Friday, May 23rd, 2025 at 3:04 PM, Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> The question is, what is really needed or missing?
>
> - a general switch case for non-integral or custom data types:
>
> will be provided by pattern matching
>
> I think what missing is the capability to benefit
> more from compiler-generated jump tables.

Will pattern matching forbid the compiler from generating a jump table
where appropriate? If the compiler can do that... then what's the
problem?

"Jump table" is an implementation detail. It's not something that
needs to be surfaced in the language, anymore than we need to surface
the ability to change the return value pointer on the stack
arbitrarily. As long as the compiler can handle these cases
efficiently, we don't need to overly care all that much about the
details of whether it's using a "jump table" or not.

> A number of posts in this thread imply that
> "a switch on non-integers is not a jump table,"
> which is totally not true. switch body is always
> the table to jump into[1], with the methods to
> preprocess the input condition varies, and
> compiler already do all kinds of preprocessing.

I guess that depends on what you mean by "jump table". I've always
understood that term to refer to an array of pointers to various
locations in code, with the indices in that table representing
something in particular.

The `switch` part takes the value, does some math based on how the
table entries are laid out, indexes the *table*, and jumps to the
location it indexed from that table.

The code being jumped into is not the table. It's just code.

A hash table could be a "jump table", but only if you *don't* do an
actual string comparison to verify that the hash is valid. Once you do
that string comparison, it ceases to be just a jump table.