Date: Fri, 23 May 2025 21:02:35 +0000
On Friday, May 23rd, 2025 at 12:03 PM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
> On Fri, May 23, 2025 at 2:32 PM Zhihao Yuan via Std-Proposals
> std-proposals_at_[hidden] wrote:
>
> > On Thursday, May 22nd, 2025 at 9:56 PM, Jeremy Rifkin rifkin.jer_at_[hidden] wrote:
> >
> > How do you want the compiler to optimize this for you?
> >
> > It should compile the switch body without
> > cases, label them with cases, record those
> > addresses, form a hash table in compiled
> > binary by mapping from string literal to the
> > addresses. Let e in switch (e) be the key
> > to lookup the table, jump to the corresponding
> > value of the key as if using a computed goto
> > Labels as Values (Using the GNU Compiler Collection (GCC))
>
>
> So... you want it to break if there's a hash collision? I'm not sure
> if I can call that an "optimization".
The entries are known before forming the
table, so collision can be avoided by
perfect hashing.
See also https://github.com/serge-sans-paille/frozen
>
> > Also note that focusing only on fallthrough isn’t very representative as most switch usage does not involve case fallthrough like this.
> >
> > Business code can have lots of and lots of
> > if...else chains comparing string. Sometimes,
> > because of a lack of fall-through, you see code
> > that just repeats. Fall-through is a stigmatized
> > name for a feature that prefixes a branch with
> > additional entry and processing. When you need
> > it, it expresses exactly the intent.
>
>
> And the vast majority of the time, you don't need it. And having it
> around as the default creates more problems than it solves.
>
> Indeed, your own code example has a subtle, unintended fallthrough
> bug. If someone adds a `case` below "second option", and doesn't put
> in a `break;` above it, then the code doesn't work correctly.
>
Compiler can catch it, and you are well-noticed
that I did not add [[fallthrough]];
> Default fall-through is (correctly) stigmatized because it breaks more
> code than it fixes.
As mentioned above, this is solved problem.
> On Fri, May 23, 2025 at 2:32 PM Zhihao Yuan via Std-Proposals
> std-proposals_at_[hidden] wrote:
>
> > On Thursday, May 22nd, 2025 at 9:56 PM, Jeremy Rifkin rifkin.jer_at_[hidden] wrote:
> >
> > How do you want the compiler to optimize this for you?
> >
> > It should compile the switch body without
> > cases, label them with cases, record those
> > addresses, form a hash table in compiled
> > binary by mapping from string literal to the
> > addresses. Let e in switch (e) be the key
> > to lookup the table, jump to the corresponding
> > value of the key as if using a computed goto
> > Labels as Values (Using the GNU Compiler Collection (GCC))
>
>
> So... you want it to break if there's a hash collision? I'm not sure
> if I can call that an "optimization".
The entries are known before forming the
table, so collision can be avoided by
perfect hashing.
See also https://github.com/serge-sans-paille/frozen
>
> > Also note that focusing only on fallthrough isn’t very representative as most switch usage does not involve case fallthrough like this.
> >
> > Business code can have lots of and lots of
> > if...else chains comparing string. Sometimes,
> > because of a lack of fall-through, you see code
> > that just repeats. Fall-through is a stigmatized
> > name for a feature that prefixes a branch with
> > additional entry and processing. When you need
> > it, it expresses exactly the intent.
>
>
> And the vast majority of the time, you don't need it. And having it
> around as the default creates more problems than it solves.
>
> Indeed, your own code example has a subtle, unintended fallthrough
> bug. If someone adds a `case` below "second option", and doesn't put
> in a `break;` above it, then the code doesn't work correctly.
>
Compiler can catch it, and you are well-noticed
that I did not add [[fallthrough]];
> Default fall-through is (correctly) stigmatized because it breaks more
> code than it fixes.
As mentioned above, this is solved problem.
-- Zhihao Yuan, ID lichray The best way to predict the future is to invent it. _______________________________________________
Received on 2025-05-23 21:02:46