www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Remove switch case fallthrough

reply rempas <rempas tutanota.com> writes:
Yeah yeah I know I know, Code that looks like C should have the 
same behavior to C. I've asked about that and I got the same 
answer. But come one! We can make an exception on this one! We 
don't need that in D as we can add more cases.

I really love the work the contributors do with D but IMO is 
things like that who really stop D from REALLY going forward in 
the next level. Doing things just for doing them NEVER helped 
anyone!
May 13 2021
next sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 13 May 2021 at 13:28:07 UTC, rempas wrote:

 Yeah yeah I know I know, Code that looks like C should have the 
 same behavior to C. I've asked about that and I got the same 
 answer. But come one! We can make an exception on this one! We 
 don't need that in D as we can add more cases.

 I really love the work the contributors do with D but IMO is 
 things like that who really stop D from REALLY going forward in 
 the next level. Doing things just for doing them NEVER helped 
 anyone!


In practice this is possible by just add another keyword. 
Something like "switch2", "switchb", can't really come up with 
good name. Then you just have a switch with break as default. 
What I have against it is that a new type of bugs will occur 
where the programmers accidentally mix up the two.
May 13 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 13 May 2021 at 13:55:10 UTC, IGotD- wrote:

 In practice this is possible by just add another keyword. 
 Something like "switch2", "switchb", can't really come up with 
 good name. Then you just have a switch with break as default. 
 What I have against it is that a new type of bugs will occur 
 where the programmers accidentally mix up the two.


Just use a different keyword than "case"? Like "when"?
May 13 2021
next sibling parent reply rempas <rempas tutanota.com> writes:
On Thursday, 13 May 2021 at 14:12:40 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 13 May 2021 at 13:55:10 UTC, IGotD- wrote:

 In practice this is possible by just add another keyword. 
 Something like "switch2", "switchb", can't really come up with 
 good name. Then you just have a switch with break as default. 
 What I have against it is that a new type of bugs will occur 
 where the programmers accidentally mix up the two.


 Just use a different keyword than "case"? Like "when"?


Exactly! We can mix things up a little! Or even add a new 
statement called "match" idk
May 13 2021
next sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 13 May 2021 at 14:25:53 UTC, rempas wrote:

 Exactly! We can mix things up a little! Or even add a new 
 statement called "match" idk


That could be possibility to add pattern matching capabilities to 
D and renew switch that way and add new features as well. D 
already has some kind of "match" but implemented as a library, 
maybe D should extend that and bring into the language.
May 13 2021
parent rempas <rempas tutanota.com> writes:
On Thursday, 13 May 2021 at 14:34:15 UTC, IGotD- wrote:

 On Thursday, 13 May 2021 at 14:25:53 UTC, rempas wrote:

 Exactly! We can mix things up a little! Or even add a new 
 statement called "match" idk


 That could be possibility to add pattern matching capabilities 
 to D and renew switch that way and add new features as well. D 
 already has some kind of "match" but implemented as a library, 
 maybe D should extend that and bring into the language.


Not "should", they "must" do it! Like I said, a language must 
always move forward! However I said my opinion, now it's up to 
them to decide if they want to do it or not...
May 13 2021
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 13 May 2021 at 14:25:53 UTC, rempas wrote:

 On Thursday, 13 May 2021 at 14:12:40 UTC, Ola Fosheim Grøstad 
 wrote:

 On Thursday, 13 May 2021 at 13:55:10 UTC, IGotD- wrote:

 In practice this is possible by just add another keyword. 
 Something like "switch2", "switchb", can't really come up 
 with good name. Then you just have a switch with break as 
 default. What I have against it is that a new type of bugs 
 will occur where the programmers accidentally mix up the two.


 Just use a different keyword than "case"? Like "when"?


 Exactly! We can mix things up a little! Or even add a new 
 statement called "match" idk


Please don't add *more* to the language. Just remove fallthrough. 
Done.
May 13 2021
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 13 May 2021 at 16:51:07 UTC, Imperatorn wrote:

 Please don't add *more* to the language. Just remove 
 fallthrough. Done.


Or better yet just leave it alone (existing deprecation to error 
is ok though). The explicit status quo is a solid situation.
May 13 2021
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 13 May 2021 at 16:56:58 UTC, Adam D. Ruppe wrote:

 On Thursday, 13 May 2021 at 16:51:07 UTC, Imperatorn wrote:

 Please don't add *more* to the language. Just remove 
 fallthrough. Done.


 Or better yet just leave it alone (existing deprecation to 
 error is ok though). The explicit status quo is a solid 
 situation.


Well, yeah. I personally don't really have a problem with adding 
break. I always do it anyway
May 13 2021
prev sibling parent Mathias LANG <geod24 gmail.com> writes:
On Thursday, 13 May 2021 at 16:56:58 UTC, Adam D. Ruppe wrote:

 On Thursday, 13 May 2021 at 16:51:07 UTC, Imperatorn wrote:

 Please don't add *more* to the language. Just remove 
 fallthrough. Done.


 Or better yet just leave it alone (existing deprecation to 
 error is ok though). The explicit status quo is a solid 
 situation.


Exactly this. The error should not go away, because it would be a 
major silent difference when porting code from C. And common, 
adding `break` doesn't have any kind of objective downside.
May 13 2021
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 13 May 2021 at 16:51:07 UTC, Imperatorn wrote:

 Please don't add *more* to the language. Just remove 
 fallthrough. Done.


That makes all C code break when ported to D with no warning.
May 13 2021
parent rempas <rempas tutanota.com> writes:
On Thursday, 13 May 2021 at 17:16:01 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 13 May 2021 at 16:51:07 UTC, Imperatorn wrote:

 Please don't add *more* to the language. Just remove 
 fallthrough. Done.


 That makes all C code break when ported to D with no warning.


Indeed, warning is needed when and if this gets implemented.
May 13 2021
prev sibling parent reply Ogi <ogion.art gmail.com> writes:
On Thursday, 13 May 2021 at 14:25:53 UTC, rempas wrote:

 Exactly! We can mix things up a little! Or even add a new 
 statement called "match" idk


Yes. Rather than changing `switch` behavior, we could add a whole 
different statement. Additionally, we could allow it to operate 
on non-constants. Basically like an `if .. else if` chain, but 
with better syntax. We could also make it more powerful, 
implementing pattern matching. And the compiler could rewrite 
`match` statement as the standard `switch` statement if it 
detects that all case values are known at compile time.

That was in my wishlist for D for a long time. I find both 
`switch` and `if .. else if` awkward, we could do better than 
that. But it seems we are in a minority here. Named arguments and 
string interpolation are far more popular and important features 
but we are still waiting for them.

There’s one more problem: Walter et al. always avoid adding new 
keywords to the language, preferring to reuse the existing ones 
whenever possible. Well, we could use `if switch`.

Since `case` statements inside `if switch` are not labels, we 
should probably bring them in line with statements like `if`: 
require curly braces if there’s more than one line, and 
parenthesis surrounding the condition.

```D
int i = 42, a = 10, b = 20;
if switch (i) {
     case (a)
         "i == a".writeln;
     case (b) {
         "i == b".writeln;
         someFunction();
     }
     default {
         "oh no".writeln;
     }
}
```
May 14 2021
next sibling parent reply David Gileadi <gileadisNOSPM gmail.com> writes:
On 5/14/21 12:39 PM, Ogi wrote:

 On Thursday, 13 May 2021 at 14:25:53 UTC, rempas wrote:

 Exactly! We can mix things up a little! Or even add a new statement 
 called "match" idk




...


 There’s one more problem: Walter et al. always avoid adding new keywords 
 to the language, preferring to reuse the existing ones whenever 
 possible. Well, we could use `if switch`.


`new switch` ;)
May 14 2021
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On Friday, 14 May 2021 at 20:53:09 UTC, David Gileadi wrote:

 On 5/14/21 12:39 PM, Ogi wrote:

 On Thursday, 13 May 2021 at 14:25:53 UTC, rempas wrote:

 Exactly! We can mix things up a little! Or even add a new 
 statement called "match" idk




 ...


 There’s one more problem: Walter et al. always avoid adding 
 new keywords to the language, preferring to reuse the existing 
 ones whenever possible. Well, we could use `if switch`.


 `new switch` ;)


`switch with out break` :P
May 14 2021
next sibling parent David Gileadi <gileadisNOSPM gmail.com> writes:
On 5/14/21 3:40 PM, ag0aep6g wrote:

 On Friday, 14 May 2021 at 20:53:09 UTC, David Gileadi wrote:

 On 5/14/21 12:39 PM, Ogi wrote:

 On Thursday, 13 May 2021 at 14:25:53 UTC, rempas wrote:

 Exactly! We can mix things up a little! Or even add a new statement 
 called "match" idk




 ...


 There’s one more problem: Walter et al. always avoid adding new 
 keywords to the language, preferring to reuse the existing ones 
 whenever possible. Well, we could use `if switch`.


 `new switch` ;)


 
 `switch with out break` :P


+1000
May 14 2021
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/14/21 6:40 PM, ag0aep6g wrote:

 On Friday, 14 May 2021 at 20:53:09 UTC, David Gileadi wrote:

 On 5/14/21 12:39 PM, Ogi wrote:

 On Thursday, 13 May 2021 at 14:25:53 UTC, rempas wrote:

 Exactly! We can mix things up a little! Or even add a new statement 
 called "match" idk




 ...


 There’s one more problem: Walter et al. always avoid adding new 
 keywords to the language, preferring to reuse the existing ones 
 whenever possible. Well, we could use `if switch`.


 `new switch` ;)


 
 `switch with out break` :P


That's just fantastic.
May 15 2021
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 14 May 2021 at 20:53:09 UTC, David Gileadi wrote:

 On 5/14/21 12:39 PM, Ogi wrote:

 On Thursday, 13 May 2021 at 14:25:53 UTC, rempas wrote:

 Exactly! We can mix things up a little! Or even add a new 
 statement called "match" idk




 ...


 There’s one more problem: Walter et al. always avoid adding 
 new keywords to the language, preferring to reuse the existing 
 ones whenever possible. Well, we could use `if switch`.


 `new switch` ;)


`static switch` ;-)
May 15 2021
prev sibling parent reply Dennis <dkorpel gmail.com> writes:
On Friday, 14 May 2021 at 19:39:09 UTC, Ogi wrote:

 But it seems we are in a minority here. Named arguments and 
 string interpolation are far more popular and important 
 features but we are still waiting for them.


I actually suspect there's a non-vocal group of D users 
dissatisfied with the old switch, though I don't think there's 
consensus on what the new switch would look like.


expressions](https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operator
/switch-expression) look appealing, and they are compatible with D's syntax.
Here's what the basic form looks like:

```D
void main() {
     int x = 3;
     string name = x switch {
         0 => "zero",
         1 => "one",
         2 => "two",
     };
}
```
Examples with pattern-matching and case guards can be found in 
the link.
May 14 2021
parent reply Ogi <ogion.art gmail.com> writes:
On Friday, 14 May 2021 at 20:58:57 UTC, Dennis wrote:

 ```D
 void main() {
     int x = 3;
     string name = x switch {
         0 => "zero",
         1 => "one",
         2 => "two",
     };
 }
 ```


This particular example can be emulated with this template:

```D
template mapSwitch(alias map)
{
	import std.traits;
	alias T = KeyType!(typeof(map));
	auto mapSwitch(T value)
	{
		switch (value) {
			static foreach (key; map.keys) {
				case key: return map[key];
			}
             default: assert(0);
		}
	}
}

void main() {
	int x = 2;
	string name = x.mapSwitch!([
		0 : `zero`,
		1 : `one`,
		2 : `two`,
	]);
}
```

Both the keys and the values must be known at compile time 
though. We can’t go around this by using lambdas because D 
doesn’t support passing function pointers as template parameters.
May 21 2021
parent Paul Backus <snarwin gmail.com> writes:
On Friday, 21 May 2021 at 19:25:22 UTC, Ogi wrote:

 On Friday, 14 May 2021 at 20:58:57 UTC, Dennis wrote:

 ```D
 void main() {
     int x = 3;
     string name = x switch {
         0 => "zero",
         1 => "one",
         2 => "two",
     };
 }
 ```


 This particular example can be emulated with this template:

 ```D
 template mapSwitch(alias map)
 {
 ```


There's also [`std.algorithm.comparison.predSwitch`][1] in 
Phobos, which does something similar.

[1]: 
http://phobos.dpldocs.info/std.algorithm.comparison.predSwitch.html
May 21 2021
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 13 May 2021 at 14:12:40 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 13 May 2021 at 13:55:10 UTC, IGotD- wrote:

 In practice this is possible by just add another keyword. 
 Something like "switch2", "switchb", can't really come up with 
 good name. Then you just have a switch with break as default. 
 What I have against it is that a new type of bugs will occur 
 where the programmers accidentally mix up the two.


 Just use a different keyword than "case"? Like "when"?


or "on", if this does not cause problems with the try catch 
construct.
May 13 2021
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/13/21 9:28 AM, rempas wrote:

 Yeah yeah I know I know, Code that looks like C should have the same 
 behavior to C. I've asked about that and I got the same answer. But come 
 one! We can make an exception on this one! We don't need that in D as we 
 can add more cases.


It's already deprecated, since 2.072. It's also been a warning since 
2.054. I'm not sure if this is intended to be removed or not, but 
removing it today would put it at a 4.5 year deprecation period, and 10 
years since it's been a warning.


 
 I really love the work the contributors do with D but IMO is things like 
 that who really stop D from REALLY going forward in the next level. 
 Doing things just for doing them NEVER helped anyone!


Nobody thinks case fallthrough is good, this is why it's a warning and 
deprecated.

-Steve
May 13 2021
next sibling parent reply rempas <rempas tutanota.com> writes:
On Thursday, 13 May 2021 at 14:15:15 UTC, Steven Schveighoffer 
wrote:

 On 5/13/21 9:28 AM, rempas wrote:

 [...]


 It's already deprecated, since 2.072. It's also been a warning 
 since 2.054. I'm not sure if this is intended to be removed or 
 not, but removing it today would put it at a 4.5 year 
 deprecation period, and 10 years since it's been a warning.


 [...]


 Nobody thinks case fallthrough is good, this is why it's a 
 warning and deprecated.

 -Steve


My mistake for not being clear, like I said to the other 
comments, I mean that we should not need the "break" anymore.
May 13 2021
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/13/21 10:27 AM, rempas wrote:

 On Thursday, 13 May 2021 at 14:15:15 UTC, Steven Schveighoffer wrote:

 On 5/13/21 9:28 AM, rempas wrote:

 [...]


 It's already deprecated, since 2.072. It's also been a warning since 
 2.054. I'm not sure if this is intended to be removed or not, but 
 removing it today would put it at a 4.5 year deprecation period, and 
 10 years since it's been a warning.


 [...]


 Nobody thinks case fallthrough is good, this is why it's a warning and 
 deprecated.


 
 My mistake for not being clear, like I said to the other comments, I 
 mean that we should not need the "break" anymore.


First step is to make implicit fallthrough an error instead of a 
deprecation. Then after a time, we might be able to make break optional.

-Steve
May 13 2021
parent reply rempas <rempas tutanota.com> writes:
On Thursday, 13 May 2021 at 16:48:36 UTC, Steven Schveighoffer 
wrote:

 First step is to make implicit fallthrough an error instead of 
 a deprecation. Then after a time, we might be able to make 
 break optional.

 -Steve


Exactly! I hope the community will think about it. Like I said, I 
don't think having some stuff like they are just to do it is a 
good thing for anyone.
May 13 2021
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 13 May 2021 at 17:52:52 UTC, rempas wrote:

 On Thursday, 13 May 2021 at 16:48:36 UTC, Steven Schveighoffer 
 wrote:

 First step is to make implicit fallthrough an error instead of 
 a deprecation. Then after a time, we might be able to make 
 break optional.

 -Steve


 Exactly! I hope the community will think about it. Like I said, 
 I don't think having some stuff like they are just to do it is 
 a good thing for anyone.


Implicit fallthrough was not deprecated "just to do it". There 
were reasons. Doing so caught bugs and was generally 
well-received. Example:

https://forum.dlang.org/post/lgoda9$23dc$1 digitalmars.com
May 13 2021
parent reply rempas <rempas tutanota.com> writes:
On Friday, 14 May 2021 at 00:42:47 UTC, Mike Parker wrote:


 Implicit fallthrough was not deprecated "just to do it". There 
 were reasons. Doing so caught bugs and was generally 
 well-received. Example:

 https://forum.dlang.org/post/lgoda9$23dc$1 digitalmars.com


Yeah but we have to add "break" every time? No ones uses this 
feature anymore (thus the warnings) because we can add more 
cases. This is what I mean by saying "doing things just to do 
them". While I agree that code that looks like C should act like 
C but I think we can make one exception here! But anyway just my 
opinion
May 13 2021
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 14 May 2021 at 06:21:10 UTC, rempas wrote:

 Yeah but we have to add "break" every time? No ones uses this 
 feature anymore (thus the warnings) because we can add more 
 cases. This is what I mean by saying "doing things just to do 
 them". While I agree that code that looks like C should act 
 like C but I think we can make one exception here! But anyway 
 just my opinion


But C supports implicit fallthrough, so by deprecating it, we did 
make an exception. Ans it's a good exception to make.
May 13 2021
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 14 May 2021 at 06:56:55 UTC, Mike Parker wrote:


 But C supports implicit fallthrough, so by deprecating it, we 
 did make an exception. Ans it's a good exception to make.


Here's what the C++ Core Guidelines say:

"Always end a non-empty case with a break. Accidentally leaving 
out a break is a fairly common bug. A deliberate fallthrough can 
be a maintenance hazard and should be rare and explicit."

This is the same reason it's deprecated in D.


https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es78-dont-rely-on-implicit-fallthrough-in-switch-statements
May 14 2021
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 14 May 2021 at 07:00:50 UTC, Mike Parker wrote:

 On Friday, 14 May 2021 at 06:56:55 UTC, Mike Parker wrote:


 But C supports implicit fallthrough, so by deprecating it, we 
 did make an exception. Ans it's a good exception to make.


 Here's what the C++ Core Guidelines say:

 "Always end a non-empty case with a break. Accidentally leaving 
 out a break is a fairly common bug. A deliberate fallthrough 
 can be a maintenance hazard and should be rare and explicit."

 This is the same reason it's deprecated in D.


 https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es78-dont-rely-on-implicit-fallthrough-in-switch-statements


Additionally, since C++17, there is the fallthrough attribute to 
be explicit that the C behaviour is actually intended.

https://en.cppreference.com/w/cpp/language/attributes/fallthrough
May 14 2021
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 14 May 2021 at 08:24:46 UTC, Paulo Pinto wrote:
ines.md#es78-dont-rely-on-implicit-fallthrough-in-switch-statements

 Additionally, since C++17, there is the fallthrough attribute 
 to be explicit that the C behaviour is actually intended.

 https://en.cppreference.com/w/cpp/language/attributes/fallthrough


Man that's ugly. I like our `goto case` better.
May 14 2021
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 14 May 2021 at 08:37:19 UTC, Mike Parker wrote:

 Man that's ugly. I like our `goto case` better.


It is an attribute to silence optional warnings (basically to 
support "linting"). It is consistent with other silencing 
attributes.

The C++ language does fall through.
May 14 2021
prev sibling next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 14 May 2021 at 08:37:19 UTC, Mike Parker wrote:

 On Friday, 14 May 2021 at 08:24:46 UTC, Paulo Pinto wrote:
 ines.md#es78-dont-rely-on-implicit-fallthrough-in-switch-statements

 Additionally, since C++17, there is the fallthrough attribute 
 to be explicit that the C behaviour is actually intended.

 https://en.cppreference.com/w/cpp/language/attributes/fallthrough


 Man that's ugly. I like our `goto case` better.


In C gcc uses comments to silence the warning.

```
case 5: ...
/* falltrough */
case 6: ...
```
May 14 2021
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 14 May 2021 at 08:37:19 UTC, Mike Parker wrote:

 On Friday, 14 May 2021 at 08:24:46 UTC, Paulo Pinto wrote:
 ines.md#es78-dont-rely-on-implicit-fallthrough-in-switch-statements

 Additionally, since C++17, there is the fallthrough attribute 
 to be explicit that the C behaviour is actually intended.

 https://en.cppreference.com/w/cpp/language/attributes/fallthrough


 Man that's ugly. I like our `goto case` better.


Lol is this real life? It's starting to look like an alien 
language
May 14 2021
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 14 May 2021 at 06:56:55 UTC, Mike Parker wrote:

 On Friday, 14 May 2021 at 06:21:10 UTC, rempas wrote:

 Yeah but we have to add "break" every time? No ones uses this 
 feature anymore (thus the warnings) because we can add more 
 cases. This is what I mean by saying "doing things just to do 
 them". While I agree that code that looks like C should act 
 like C but I think we can make one exception here! But anyway 
 just my opinion


 But C supports implicit fallthrough, so by deprecating it, we 
 did make an exception. Ans it's a good exception to make.


And even C compilers warn now about implicit fallthrough (gcc 
since version 8 with -Wall).
May 14 2021
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 5/13/2021 7:15 AM, Steven Schveighoffer wrote:

 Nobody thinks case fallthrough is good, this is why it's a warning and
deprecated.


I used to, but I've come around :-)
May 13 2021
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 13 May 2021 at 13:28:07 UTC, rempas wrote:

 Yeah yeah I know I know, Code that looks like C should have the 
 same behavior to C. I've asked about that and I got the same 
 answer. But come one! We can make an exception on this one! We 
 don't need that in D as we can add more cases.

 I really love the work the contributors do with D but IMO is 
 things like that who really stop D from REALLY going forward in 
 the next level. Doing things just for doing them NEVER helped 
 anyone!


switch case fallthrough is already considered deprecated. If you 
use it, the compiler will produce the following warning:

     Deprecation: switch case fallthrough - use 'goto case;' if 
intended

I'm not sure what the process is for turning a deprecation like 
this into an error (maybe a -preview/-revert switch is needed?), 
but presumably the intent is for that to happen at some point. In 
the meantime, you can do it manually by compiling with the `-de` 
switch, which tells the compiler to give errors instead of 
warnings for deprecations.
May 13 2021
parent reply IGotD- <nise nise.com> writes:
On Thursday, 13 May 2021 at 14:15:39 UTC, Paul Backus wrote:

 switch case fallthrough is already considered deprecated. If 
 you use it, the compiler will produce the following warning:

     Deprecation: switch case fallthrough - use 'goto case;' if 
 intended


I kind of read between the lines and got it to that TS wanted to 
remove the mandatory break completely. Could be wrong though.
May 13 2021
parent rempas <rempas tutanota.com> writes:
On Thursday, 13 May 2021 at 14:22:21 UTC, IGotD- wrote:

 On Thursday, 13 May 2021 at 14:15:39 UTC, Paul Backus wrote:

 switch case fallthrough is already considered deprecated. If 
 you use it, the compiler will produce the following warning:

     Deprecation: switch case fallthrough - use 'goto case;' if 
 intended


 I kind of read between the lines and got it to that TS wanted 
 to remove the mandatory break completely. Could be wrong though.


Yes this is what I mean! There is no reason to have to use break! 
It is just annoying imo!
May 13 2021
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 13 May 2021 at 13:28:07 UTC, rempas wrote:

 Yeah yeah I know I know, Code that looks like C should have the 
 same behavior to C. I've asked about that and I got the same 
 answer. But come one! We can make an exception on this one! We 
 don't need that in D as we can add more cases.

 I really love the work the contributors do with D but IMO is 
 things like that who really stop D from REALLY going forward in 
 the next level. Doing things just for doing them NEVER helped 
 anyone!


what are you proposing is not clear. Is that

"turn the deprecation into an error for good" or "remove the 
deprecation" ?
May 13 2021