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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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