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