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