Deprecate case-variables

Quirin Schroll qs.il.paperinik at gmail.com
Tue May 16 17:28:46 UTC 2023


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, also it is bad that it allows for a non-mutable 
variable, but not for an arbitrary expression. It is inconsistent 
because it a 
[CaseRangeStatement](https://dlang.org/spec/statement.html#case-range) cannot use run-time values. That makes it both weird and less useful than it could be.

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

C# case guards have been mentioned, but guards aren’t the same as 
run-time value labels. In C#, the label must still be 
compile-time, but it can be a pattern, and there is a pattern 
that matches any value; followed by a guard, it gets you where 
you want. That is not available in D.


More information about the Digitalmars-d mailing list