Deprecate case-variables

[max haughton]

On Tuesday, 16 May 2023 at 17:28:46 UTC, Quirin Schroll wrote:
> On Sunday, 14 May 2023 at 23:11:25 UTC, Walter Bright wrote:
>> https://github.com/dlang/dmd/pull/14829
>>
>> Case variables are:
>>
>> "The case expressions in ArgumentList are a comma separated 
>> list of expressions. Each expression must evaluate to a 
>> compile-time value or array, or a **runtime initialized const 
>> or immutable variable of integral type**. Each expression must 
>> be implicitly convertible to the type of the switch Expression.
>>
>> Compile-time case values must all be distinct. Const or 
>> immutable runtime variables must all have different names. If 
>> two case expressions share a value, the first case statement 
>> with that value gets control."
>>
>> https://dlang.org/spec/statement.html#switch-statement
>>
>> Should we deprecate the case variables?
>>
>> Pro: for the sake of simplicity, as it is a surprising and 
>> presumably little-used feature.
>>
>> Con: people don't like breaking existing code, and the feature 
>> isn't causing any known problems.
>>
>> I hope we can reach consensus.
>
> The feature is bad because whether a value is compile-time or 
> run-time is non-trivial to determine and the behavior is vastly 
> different,
Having different behaviour in this case is arguably desirable 
given that the
main use of these that I can think of (and have actually used) is 
basically injected
fuzzy special cases into switch statements without completely 
spoiling the flow of the code too much (i.e. them having a 
priority in that case isn't that unreasonable).

> The fact that they work with `goto case` makes them feel even 
> more wrong.

In the use case above being able to use them like a normal 
CaseStatement makes sense.