On Wed, Feb 12, 2025 at 11:41:01AM +0000, Simon Cooke via Std-Proposals wrote:
> As Sebastian said, this is probably best handled via an attribute.
>
> You can do this today with #pragma unroll (on many platforms), although
> generally you might get better results via PGO.
>
> To the original proposal...
>
> I can't think of any time I've said to myself "I desperately wish I had an
> easier way to write this for loop". IMO, the way it works today is not
> particularly onerous. And changing it just increases the cognitive load for
> people who are new to the language.
>
> Usually you either have an iterator you're working with and you don't care
> about indexing (so use ranged for), or you're using indexing, and that's
> either really simple or complex with oddball termination cases - I don't
> see the win here. It feels like a Pythonism creeping in.

If we are talking of loop Pythonisms then a loop else branch does add some
value as that case often is a bit contrieved to test for. (The else branch
of a loop is executed when the loop condition fails to run the loop more
times) (loop else is obviously not viable in c++ as it changes the meaning of

if (cond)
 for (decl; expr; expr)
  statement();
else
 action_if_cond_is_false();
).

/MF

> Simon
>
>
>
>
> On Wed, Feb 12, 2025, 10:59 Sebastian Wittmeier via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> > That is the domain of the optimizer.
> >
> > Even inline functions does not mean any longer that they are inlined (just
> > that they can be defined multiple times and put in headers).
> >
> > If you want to standardize a hint to the optimizer, a (standardized)
> > attribute would be a good choice, as it does not change the meaning and
> > behaviour of the code.
> >
> >
> > -----Ursprüngliche Nachricht-----
> > *Von:* Filip via Std-Proposals <std-proposals_at_[hidden]>
> > *Gesendet:* Mi 12.02.2025 11:04
> > *Betreff:* Re: [std-proposals] for-loops revision (simplification and new
> > syntax)
> > *An:* std-proposals_at_[hidden];
> > *CC:* Filip <fph2137_at_[hidden]>; Proposals C++ <
> > std-proposals_at_[hidden]>;
> > Maybe to force the compiler to unroll the loop we could use:
> >
> > ‘’’
> > inline for
> > ‘’’
> >
> > I’ve seen similar syntax in zig.
> >
> > Cheers, Filip
> >
> > Wiadomość napisana przez Jonathan Wakely via Std-Proposals <
> > std-proposals_at_[hidden]> w dniu 12 lut 2025, o godz. 10:46:
> >
> > 
> >
> >
> > On Wed, 12 Feb 2025, 02:42 Henry Miller via Std-Proposals, <
> > std-proposals_at_[hidden]> wrote:
> >
> >
> >
> > On Tue, Feb 11, 2025, at 12:03, Pau Miquel Montequi Hernandez via
> > Std-Proposals wrote:
> > > @Andrey Semashev
> > >
> > >> Quite honestly, looping with a counter is by far not the most common
> > kind
> > >> of loops you write in real code. It is the simplest kind of loop that
> > they
> > >> teach in clases
> > >
> > >
> > > Looping with a counter might not be the most common kind of loop written,
> > > but indeed it is the simplest kind of loop that they teach in classes.
> > "*Make
> > > simple things simple*" is a good principle that improves readability and
> > > teachability of the language. Also this proposal can be seen as a way to
> > > homogenize the loops, if something looks like a range, should be iterable
> > > as a range; right now C++11's range-for loop is used for many constructs
> > > that look and behave like ranges but leave aside the most simple of them:
> > > just iterate from number A to nomber B, in my opinión this is an
> > oversight.
> >
> > many developes have adopted a no loops ever policy. It turns out everytime
> > you think loop you can reach for std:: where you will find an algorithm
> > that is more expressive and safer to get the same result. I'm not 100%
> > there but I'm close.
> >
> > As such the only use I have for loops is teaching how things work inside.
> > for students being explict about exactly what is happening is comforting
> > even if most often the loop always looks the same. Perhaps the syntax could
> > be improved but is it worth making it easier to use something rarely used?
> >
> >
> > Does adding several new ways to write a loop make things easier?
> >
> > Especially when some of the suggestions add or remove parts of the usual
> > syntax. It seems to me that it would make it harder to read the loop header
> > because you'd have to examine it more carefully to see what it was doing
> > (especially the suggestion for multiple init statements).
> >
> > And it's all just syntactic sugar, not enabling anything new which can't
> > be done (quite easily!) today.
> >
> > The range-based 'for' loop added in C++11 actually enabled something new
> > which couldn't be done in C++03: iterating over arrays or containers with
> > uniform syntax, without needing to write 'typename R::iterator' or
> > 'typename R::const_iterator'. And even that became redundant with 'auto'
> > and ' std::begin' added at the same time as the new 'for' loop.
> >
> >
> >
> >
> > --
> > 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
> >

> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals