> the order could be implementation-defined? Or even no guaranteed order.

Please don’t leave this implementation-defined or unspecified. There’s no
reason to create portability issues here.


Cheers,
Jeremy



On Fri, Mar 14, 2025 at 13:19 Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Perhaps better something like
>
>
>
> for (auto e : std::values(someEnum))
>
>
>
> the order could be implementation-defined? Or even no guaranteed order.
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Andre Kostur via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Fr 14.03.2025 18:18
> *Betreff:* Re: [std-proposals] for loop enhancement
> *An:* std-proposals_at_[hidden];
> *CC:* Andre Kostur <andre_at_[hidden]>;
> Re: using enum in for loop.
>
> for (auto e: <type>) seems weird (and messes with the grammar). And
> opens the door to 'for ( auto e : unsigned char )', or 'for (auto e :
> long)'. Yes, I realize that's not what you're asking for now, but it
> seems like a natural next step.
>
> Also two other clarifications would also need to happen: what about
> duplicate values, and in what order will that loop across the enum
> values (recall: one can define an enum in an arbitrary order).
>
> On Fri, Mar 14, 2025 at 9:43 AM Filip via Std-Proposals
>
>
> <std-proposals_at_[hidden]> wrote:
> >
> > I want to ask for your comments about couple of different for loops
> ideas that I had recently:
> >
> > 1. using enum in for loop:
> > ```
> > for (auto e : someEnum) {...}
> > ```
> >
> > Since compiler knows the elements of `ENUM` it should be able to easily
> unroll the loop or iterate over the elements of enum.
> >
> > 2. Forcing unroll with a keyword and not `#pragma`
> > ```
> > inline for ( … )
> > ```
> > It could force the unroll like similar construct does in zig.
> > This syntax already exists and we could probably easily implement it.
> >
> > 3. Run loop N times
> > ```
> > for ( 5 )
> > ```
> > Running for loop N number of times is a common issue e.g. N tries to
> connect to the server.
> > This way would not pollute the namespace with additional `int i` that we
> frankly don’t use.
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>