https://issues.dlang.org/show_bug.cgi?id=23544

Bolpat <qs.il.paperinik@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qs.il.paperinik@gmail.com

--

https://issues.dlang.org/show_bug.cgi?id=23544

anonymous4 <dfj1esp02@sneakemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |spec

--- Comment #1 from anonymous4 <dfj1esp02@sneakemail.com> ---
This would be DIP.

--

https://issues.dlang.org/show_bug.cgi?id=23544

mhh <maxhaton@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxhaton@gmail.com

--- Comment #2 from mhh <maxhaton@gmail.com> ---
What would a static foreach inside an enum (without use of mixin) be able to
express?

--

https://issues.dlang.org/show_bug.cgi?id=23544

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

https://issues.dlang.org/show_bug.cgi?id=23544

--- Comment #3 from Bolpat <qs.il.paperinik@gmail.com> ---
(In reply to mhh from comment #2)
> What would a static foreach inside an enum (without use of mixin) be able to
> express?

You can generate members based off of other members. It’s very similar to `static foreach` generating `case` labels in a `switch` statement. Note that you excluding mixin proves my point, that is a use case. A relevant observation is that how well string mixins can be understood correlates strongly with their length: A simple, single declaration string mixin inside a `static foreach` is vastly preferable to a string mixin creating the enum and its members in one go.

As another example, conditional compilation using `static if` can make members (un)available depending on compile-time information. There’s lots of potential examples where one would like that. An enum member can specify certain actions, some of which might not be available on e.g. certain architectures.

--

https://issues.dlang.org/show_bug.cgi?id=23544

--- Comment #4 from Bolpat <qs.il.paperinik@gmail.com> ---
(In reply to anonymous4 from comment #1)
> This would be DIP.

What is that assertion based on?

DIPs are for additions of major language features or changes that require deprecation.

An alternative syntax that is a pure addition does not warrant a DIP. It definitely would if we were to remove the existing `enum` syntax instead, but that’s not what I’m suggesting.

--