Thread overview
[Issue 20613] String switch in -betterC fails for 7+ labels
Feb 27, 2020
Dlang Bot
Feb 27, 2020
Dlang Bot
Jun 08, 2022
Dennis
February 26, 2020
https://issues.dlang.org/show_bug.cgi?id=20613

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--- Comment #1 from Steven Schveighoffer <schveiguy@yahoo.com> ---
The issue is that the betterC restrictions are being applied during CTFE. I would say that this will be fixed as soon as issue 19268 is fixed. I would say this is really a duplicate. But this use case is important.

--
February 26, 2020
https://issues.dlang.org/show_bug.cgi?id=20613

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=19268

--
February 26, 2020
https://issues.dlang.org/show_bug.cgi?id=20613

--- Comment #2 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Simen Kjaeraas from comment #0)
> Testing indicates the whole anonymous lambda dance used there could be
> replaced with
>     static immutable cases = [caseLabels];

Indeed, I would think that a valid solution. The caseLabels are passed at compile time, so I don't see why they would need to be idup'd.

I'm not sure why Martin did it the way he did. I'll ask him.

--
February 27, 2020
https://issues.dlang.org/show_bug.cgi?id=20613

--- Comment #3 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Steven Schveighoffer from comment #2)
> I'm not sure why Martin did it the way he did. I'll ask him.

No response from him, but I tried using your suggestion. It doesn't work (std.datetime fails to compile).

The issue is that the template is passed in the string literals as the type of
the value to switch on. So if you pass in a const(char)[] to test, the literals
are passed in as const(char)[].

Which means, even though they are compile-time literals, they don't convert to
immutable(char)[].

But I have found an answer that is less complex and just uses a cast. PR imminent.

--
February 27, 2020
https://issues.dlang.org/show_bug.cgi?id=20613

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #4 from Dlang Bot <dlang-bot@dlang.rocks> ---
@schveiguy created dlang/druntime pull request #2962 "Fix 20613 - String switch in -betterC fails for 7+ labels" fixing this issue:

- Fix issue 20613. Switch statements of 7 or more strings should not
  depend on druntime for operation.

https://github.com/dlang/druntime/pull/2962

--
February 27, 2020
https://issues.dlang.org/show_bug.cgi?id=20613

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Dlang Bot <dlang-bot@dlang.rocks> ---
dlang/druntime pull request #2962 "Fix 20613 - String switch in -betterC fails for 7+ labels" was merged into stable:

- a836cf4a9ead5ed6edee09f3ba03e52fef4f8e66 by Steven Schveighoffer:
  Fix issue 20613. Switch statements of 7 or more strings should not
  depend on druntime for operation.

https://github.com/dlang/druntime/pull/2962

--
June 08, 2022
https://issues.dlang.org/show_bug.cgi?id=20613

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |raoofha@yahoo.com

--- Comment #6 from Dennis <dkorpel@live.nl> ---
*** Issue 20573 has been marked as a duplicate of this issue. ***

--