[Proposal] Allow goto case to jump to any case label not just static constants

[hernot]

Hi
had the rare case that i needed the case goto in conjunction with enumeration values encoding the strength of a signal. IF the signal only those operation should be done which safely can be applied to the weak signal and when when the signal state is good all operations should be run

Enum SignalState {
FlatLine,
Weak,
Strong
};

As goto case SignalState.Weak;

Is not a valid statement my solution was the following so far

switch ((long)state ) {
case (long)SignalState.Strong : {
// run the operations only to be applied to Strong signals
goto case -1111111111;
}
case (long)SignalState.Weak:
case -1111111111: {
// run operation even applicable to Weak signals
break
}
case (long)SignalState.FlatLine : {
// report flatline
}
default : {
// handle any unknown state and programmers error eg. by throwing an exception
}
}

Therefore i would suggest to introduce the following type of case label of alike

case goto <goto_only_label>:

where the <goto_only_label> can be any static constant accepted by goto case independent of the type of values the switch statement is switching upon and any non whitespace string which would be accepted for normal goto labels.

• Its only purpose would be to act as valid target of goto case statement in case the switch statement does not use static constants but Enum, patterns etc. No code besides the one for the mere goto case semantic should be emitted by the frontend and backend compiler.

• It must immediately precede or follow another valid case label like

  case SignalState.Strong: {
  // process strong
  case goto CommonWeakAndStrong;
  }
  case SignalState.Weak:
  case goto CommonWeakAndStrong: {
  // process
  break;
  }

or

case SignalState.Strong: {
// process strong
case goto CommonWeakAndStrong;
}
case goto CommonWeakAndStrong:
case SignalState.Weak: {
// process
break;
}

• the following would be for example invalid

  case SignalState.Strong: {
  // process strong
  case goto CommonWeakAndStrong;
  }
  case SignalState.Weak: {
  // process weak only
  case goto CommonWeakAndStrong;
  }
  case goto CommonWeakAndStrong: {
  // process
  break;
  }

• The difference to the casting solution shown initially would be the value -111111111 is a valid value for (long) even though it is highly unlikely that the SignalState enum will contain a Label representing it, while the case got < goto_only_label> would not be valid outside its switch statement.

[svick]

As goto case SignalState.Weak; is not a valid statement

I don't understand, this code compiles fine for me:

switch (state) {
    case SignalState.Strong : {
        // run the operations only to be applied to Strong signals
        goto case SignalState.Weak;
    }
    case SignalState.Weak : {
        // run operation even applicable to Weak signals
        break;
    }
    case SignalState.FlatLine : {
        // report flatline
        break;
    }
    default : {
        // handle any unknown state and programmers error eg. by throwing an exception
        break;
    }
}

Can you explain what exactly is the code that didn't work for you and what is the error you got?

[GeorgeAlexandria]

Hi,
An another good example to supports a little more cases for goto it's jump to case in the switch statement with the pattern label:

...
switch(expression)
{
    case string value:
        // do something and then jump to another case
        goto case int;

    case int _:
        // do something
        break;

    case CustomType myValue:
        // do something and then jump to another case
        goto case CustomBaseType;
        break;

    case CustomBaseType myBaseValue:
        // do something
        break;
}

goto can jump to constant expressions that must be a fully evaluated expression at compile-time. A some defined type(int, string and so on) is fully evaluated expression at compile-time. Therefore, if I'm not missing something about defined type, the example above should be support by compiler in the future release, doesn't it?

[svick]

An another good example to supports a little more cases for goto it's jump to case in the switch statement with the pattern label

How exactly would that work? Consider this code:

switch (expression)
{
    case string value:
        goto case int;

    case int i:
        Console.WriteLine(i);
        break;
}

If expression was a string, what would be the value of i after the goto?

goto can jump to constant expressions that must be a fully evaluated expression at compile-time. A some defined type(int, string and so on) is fully evaluated expression at compile-time. Therefore, if I'm not missing something about defined type, the example above should be support by compiler in the future release, doesn't it?

You're reading an old version of the spec (it's an unofficial spec for C# 6.0; there is currently no official spec for anything newer than C# 5.0) and attempting to directly apply that to a new version of the language. That's not how it works; when a new version of the language affects an existing construct (like the swtich statement), what the old version of the spec says may no longer apply. (It's only guaranteed to apply if you don't use any new features.)

[GeorgeAlexandria]

How exactly would that work? Consider this code:

Compiler should determine, because it can, that the current case pattern label type is derived from the type (or have implicit conversion) where you try to jump with goto. For current example it doesn't allow to jump from string value to int i, but allows jump from CustomType myValue to CustomBaseType myBaseValue. Under "allows" I mean that compiler get a compilation error or not.

You're reading an old version of the spec

I think about it, but I didn't find anything new in the proposal about goto and the new pattern matching in switch statement.

[hernot]

Sorry for the late response:

Hm Strange, could have bet that i read somewhere in the docs (maybe old
ones) that only constant case labels are possible, further did not
expect that in this case dotnet/c# and the version of rosetta/c# (used by my mono/ version n 2.7.0.62620 ) differ
so much. Further i seem to have missed the following
modification is allowed and works also in the aforementioned version of roslyn (https://github.com/dotnet/roslyn) from the docs, and my search on stackoverflow and other
discussion sources:

https://sharplab.io/#v2:C4LgbgpgTglgZgTwD4AEBMACAwhg3gWACgMSMUAWDAWQAoBlGAcwDsBDAGzuFeAgwGduvAJR4ipCQIDuMYAGMAFhhqCeEUQWKTtc1vz4MWHLmoB0XKAHtmjDCDFbtTjAHoXGKAFdmGYAr6WAA7QPDDW/BjW7Ai+lhgARnysgYHsMBAAJrEYFta2/Exs7Pzizk6MlsBxWJYAtrXWAGKWUADqEKwA1gCCzBkA4paWGQDcpWUYAL7jZbr6OYXGQhCm7V12M8419U0taz19g8P2mhPabh7ekcFQodYYEJA+yakwuvHsfFUY+wKLxZszvEoB1OmNHGVphDnHMDP8TLxTI12DwADIwZh8E6AiYXEGBFrADBwFHANKYnFlYGg8FnKaUiQZCBwViedhE7HQs4XBSsPqfDB8mLeTrMSxSHyqXiCvoYQJWRi3erQCLQKxQB6MUwJGJ+KwyGwyh4ADzkEECwDCzAZTmpXVpZyhzidpChUKIEGYnlqCyMnGWDgkyLRGIgABoZvsIxDcjYiJMRkA=

Which is exactly what i thought I'm the first to propose ;-) Thank you
very much anyway for your time ;-) and the most universal.