digitalmars.D - Deprecate case-variables
- Walter Bright (16/16) May 14 2023 https://github.com/dlang/dmd/pull/14829
- Richard (Rikki) Andrew Cattermole (2/2) May 14 2023 No complaints here.
- Guillaume Piolat (4/5) May 15 2023 I didn't know it existed, and I don't think I'd want to use that.
- Nick Treleaven (1/5) May 16 2023
- 12345swordy (3/21) May 15 2023 Are there better implementation of this in other languages?
- 12345swordy (4/8) May 15 2023 Found it, it is called case_guard.
- Quirin Schroll (14/32) May 16 2023 The feature is bad because whether a value is compile-time or
- max haughton (10/42) May 16 2023 Having different behaviour in this case is arguably desirable
- Meta (4/22) May 16 2023 Aren't case variables useful for creating jump tables much more
- Paul Backus (18/21) May 16 2023 "Case variables" refers specifically to the use of a runtime
- Monkyyy (4/5) May 16 2023 Idk if Ive ever used it or I end up using it consitently
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.
May 14 2023
"Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> No complaints here. Seems like something a scream test should be used for, so deprecate away!
May 14 2023
On Sunday, 14 May 2023 at 23:11:25 UTC, Walter Bright wrote:Should we deprecate the case variables?I didn't know it existed, and I don't think I'd want to use that. Seems hard to predict what the compiler will do. What if the variable has same value as another case? So I'd vote for removal.
May 15 2023
On Monday, 15 May 2023 at 10:47:51 UTC, Guillaume Piolat wrote:Seems hard to predict what the compiler will do. What if the variable has same value as another case?If two case expressions share a value, the first case statement with that value gets control.
May 16 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.Are there better implementation of this in other languages? -Alex
May 15 2023
On Monday, 15 May 2023 at 14:20:21 UTC, 12345swordy wrote:On Sunday, 14 May 2023 at 23:11:25 UTC, Walter Bright wrote:Found it, it is called case_guard. https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/statements#1383-the-switch-statement -Alex[...]Are there better implementation of this in other languages? -Alex
May 15 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. 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.
May 16 2023
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: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).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,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.
May 16 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.Aren't case variables useful for creating jump tables much more succinctly? It seems like that is a use case that should be carefully considered.
May 16 2023
On Tuesday, 16 May 2023 at 17:31:58 UTC, Meta wrote:Aren't case variables useful for creating jump tables much more succinctly? It seems like that is a use case that should be carefully considered."Case variables" refers specifically to the use of a runtime variable in a case label, like this: int x = 1; const int n = readln.strip.to!int; switch (x) { case n: // <-- case variable writeln("x == n"); break; default: writeln("x != n"); break; } Even if we remove case variables, the ability to specify multiple values in a single case label will remain, as long as those values are all compile-time constants. So this change would not make it any harder to write succinct jump tables.
May 16 2023
On Sunday, 14 May 2023 at 23:11:25 UTC, Walter Bright wrote:https://github.com/dlang/dmd/pull/14829Idk if Ive ever used it or I end up using it consitently Maybe put a warning that says "if you see this depercation say so on the forums, and share the code"
May 16 2023