Hello,

Based on the discussion around the switch statement and whether there should be an implicit break or not, I've been learning about how it's expanded out during compilation to see how hard it would be to implement something like a golang "fallthrough" opcode.  I ran into the following interesting example, where it seems like we don't insist that the default case comes last, and we allow multiple default cases (only the first will match).  Should we be more strict, and implement some of these rules inside a verify_switch_statement(), similar to the looping opcode verifications?  We could also put the rule in there to enforce the fallthrough opcode being the last opcode of the block, and disallowing it in the default block.

I've pasted the example I was playing with at the bottom.  I'd be happy to work on the verification and/or the new opcode if folks think it's worthwhile.

Best,
Scott

=========

<CsoundSynthesizer>

<CsOptions>
-o dac
</CsOptions>

<CsInstruments>

instr 1
    switch p4
        case 2
            prints "got 2\n"
        default
            prints "got default\n"
        default
            prints "got the second default\n"
        case 3
            prints "got 3\n"
    endsw
endin

</CsInstruments>

<CsScore>
i1 0 1 3
</CsScore>

</CsoundSynthesizer>

that's a good idea to improve the semantics checker. I could look into it, made a ticket https://github.com/csound/csound/issues/2316

On Tue, 21 Oct 2025 at 08:56, Scott Sitar <scottsitar@gmail.com> wrote:

Hello,

Based on the discussion around the switch statement and whether there should be an implicit break or not, I've been learning about how it's expanded out during compilation to see how hard it would be to implement something like a golang "fallthrough" opcode.  I ran into the following interesting example, where it seems like we don't insist that the default case comes last, and we allow multiple default cases (only the first will match).  Should we be more strict, and implement some of these rules inside a verify_switch_statement(), similar to the looping opcode verifications?  We could also put the rule in there to enforce the fallthrough opcode being the last opcode of the block, and disallowing it in the default block.

I've pasted the example I was playing with at the bottom.  I'd be happy to work on the verification and/or the new opcode if folks think it's worthwhile.

Best,
Scott

=========

<CsoundSynthesizer>

<CsOptions>
-o dac
</CsOptions>

<CsInstruments>

instr 1
    switch p4
        case 2
            prints "got 2\n"
        default
            prints "got default\n"
        default
            prints "got the second default\n"
        case 3
            prints "got 3\n"
    endsw
endin

</CsInstruments>

<CsScore>
i1 0 1 3
</CsScore>

</CsoundSynthesizer>