Hi Andrey,   you may have good reasons for not yet supporting/using some new features like modules in your C++ development environment yet.   And this well explains your stance in regards to using enumerate in this case.   However, for specifying C++26 and beyond modules should IMHO be considered as the default, when talking about small improvements (saving a few characters to define/increment a loop variable), especially if a compatible header solution exists at the same time.   For the given short non-generic-code example, I would also specify and increment the loop variable manually, even with modules, and would prefer it to automatically assigned variables.   If we go that route (automatically assigned variables), we should have a look at Perl/Raku with $_, $1, ..., and the experience gained there, not make a specific solution only for for loops.   Best, Sebastian   -----Ursprüngliche Nachricht----- Von:Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 03.03.2023 10:17 Betreff:Re: [std-proposals] Array Index in Range-based For Loops An:std-proposals_at_[hidden]; CC:Andrey Semashev <andrey.semashev_at_[hidden]>; On 3/3/23 07:50, Jason McKesson via Std-Proposals wrote: > On Thu, Mar 2, 2023 at 3:11 PM Andrey Semashev via Std-Proposals > <std-proposals_at_[hidden]> wrote: >> >> On 3/2/23 19:13, Jason McKesson via Std-Proposals wrote: >>> On Thu, Mar 2, 2023 at 4:12 AM Frederick Virchanza Gotham via >>> Std-Proposals <std-proposals_at_[hidden]> wrote: >>>> >>>> On Thu, Mar 2, 2023 at 12:19 AM Thiago Macieira via Std-Proposals >>>> <std-proposals_at_[hidden]> wrote: >>>>> >>>>>>> I'm not gonna include a header file and use that horrible syntax. >>>>>>> Having an implicit variable called "__i" would be much better. >>>>>> >>>>>> What would it be called in an inner loop? __j? >>>> >>>> >>>> How about the outermost is __i, and then the next inner one is __j, >>>> then __k, until we get to __z. That would accommodate 18 nested loops. >>>> >>>> for ( auto &container : container_of_containers ) >>>> { >>>>     cout << __i << endl; >>>> >>>>     for ( string &e  : container ) >>>>     { >>>>         cout << __i * __j << end; >>>> >>>>         for ( char const c : e ) >>>>         { >>>>             cout << __k << " originating from " << __i << endl; >>>>         } >>>>     } >>>> } >>> >>> Here's a better idea: let's not make confusing, trivial changes to the >>> language for the *minor* comfort of having an index generated by the >>> compiler. The difference between `for(string &e: container)` and >>> `for(auto[i, &e]: enumerate(container))` is too insubstantial to >>> bother with. And it's not like this isn't a common idiom or anything; >>> Python programmers do this all the time. >> >> Using `enumerate` requires one to include a nontrivial amount of code, >> most of which, I presume, is unrelated to `enumerate`. And it doesn't >> really provide that much convenience benefit in return. So given the >> choice, I would rather avoid including the header and define the counter >> variable myself. > > C++23 will have module support for the standard library. `import std;` > will cost the same no matter how much stuff is in the standard > library, so that's no longer a relevant concern. Modules don't exist in my environment and won't exist for a very long time. And their performance benefit is yet to be seen. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals