Support for a switch operation

[SimonCockx]

It is often useful to model a case analysis based on an enum, string or number, e.g.,

if input = MyEnum -> VALUE1
then ...
else if input = MyEnum -> VALUE2
then ...
...
else ...

It would be useful to have a shorthand operation for this, e.g.,

input switch
    VALUE1 then ...,
    VALUE2 then ...,
    ...
    default ...

In case of switching over an enum value, Rune would validate that all enum values have been exhausted, otherwise indicating to the modeller that they forgot a case. As a catch-all, the default keyword can optionally be used at the end. This validation would improve consistency while refactoring, as new enum values will automatically indicate to the modeller which expressions should be updated.

In case of switching over basic types such as strings or numbers, no validation would be present, and a default empty is assumed implicitly.

Implementation consequences

The Rune language adds a new expression to its syntax. Code generators supporting expressions (Java, Python) will need to implement its semantics.

[lolabeis]

Looks good. And it would be the same syntax if switching on a choice type (i.e. implementing no. 3 in #797)?

[SimonCockx]

Indeed, the same syntax could be used to switch over choice types as well in the future.

[manel-martos]

I think this is a great addition into the DSL expressions. As it was already commented during the Technical Architecture Working Group, the break is assumed which avoids modelers to apply the same expression to multiple cases without code replicability. Languanges such as Java allow it so, how will DSL represent such cases?

e.g.
input switch VALUEA, VALUEB then runAB, VALUEC then runC, default ...

[SimonCockx]

@manel-martos Good question. Right now, the expression will have to be repeated, e.g.,

input switch
    VALUEA then exprAB,
    VALUEB then exprAB,
    VALUEC then exprC

This is the case in other programming languages such as Haskell as well. However, if this pattern often arises in the CDM or other models, then I think it would indeed be valuable to have such a feature, e.g.,

input switch
    VALUEA, VALUEB then exprAB,
    VALUEC then exprC

Feel free to raise a separate feature request so we can keep track of the discussion there.