Date: Mon, 10 Feb 2025 22:41:38 +0100
I love the idea of simpler loops.
‘’’
for (int i = 0; i < 42) { … } // run [0, 42)
‘’’
In my opinion if the compiler knows what the limits are it should apply ++i or —i.
‘’’
for (int i : 0 … 42 ) { … } // run [0, 42)
‘’’
That version would be probably my preferred version since it could simply mean taking i from range literal from 0 up to but excluding 42.
The range literal could be reused elsewhere.
‘’’
for ( N ) { … } // run N amount of times
‘’’
Many times I’ve needed to have a simple way to run N amount of times without specifying the loop iterator.
Cheers, Filip
Wiadomość napisana przez Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> w dniu 10 lut 2025, o godz. 21:49:
AW: [std-proposals] for-loops revision (simplification and new syntax) Perhaps we can simplify
for (auto [b,e,o] = tuple<T1,T2,T3>(...); ...)
to
for (auto<T1, T2, T3> [b, e, o] { ... }; ...);
or
for (auto [T1 b, T2 e, T3 o] { ... }; ... );
-----Ursprüngliche Nachricht-----
Von: Jonathan Wakely via Std-Proposals <std-proposals_at_[hidden]>
Gesendet: Mo 10.02.2025 20:20
Betreff: Re: [std-proposals] for-loops revision (simplification and new syntax)
An: Pau Miquel Montequi Hernandez <pau.montequi_at_[hidden]>;
CC: Jonathan Wakely <cxx_at_[hidden]>; C++ Proposals <std-proposals_at_[hidden]>;
On Mon, 10 Feb 2025, 17:15 Pau Miquel Montequi Hernandez, <pau.montequi_at_[hidden]> wrote:Sorry for my misunderstanding Jonathan,Indeed "I don't want to include a header" is not a justification, it is less nowadays if we just "import std;" as a whole.Indeed. I didn't mention that because it's easy and glib to say "modules fixes that!" but in practice most people aren't able to rely on them yet.My point is that something different can be achieved that is not possible with the tuple approach, like assigning an explicit type to each symbol, with auto […] = std::tuple(…) we are limited to use whatever type the compiler deduces which is not always the intention.The explicitness of for (type_a a = …; type_b b = …; type_c c = …; condition, expression) provides in my opinion more control (I want exactly this type) and sense of intentionality (I wanted this to be like that), I cannot deny that it is not ideal to pollute the for with so much noise though, we can always move variables to the enclosing scope if we don't mind giving them a bigger-than-required scope and lifetime or use the tuple approach which is less noisy but more broad.If you make the tuple solution more noisy, then you can have the precise control over types that you want:for (auto [b,e,o] = tuple<T1,T2,T3>(...); ...)This gets quite noisy, but it's still something that's possible today, and uses language features that are useful in more places than just for loops.And the multiple-init 'for' loop quickly gets noisy too.Missatge de Jonathan Wakely <cxx_at_[hidden]> del dia dl., 10 de febr. 2025 a les 17:46:On Mon, 10 Feb 2025 at 16:03, Pau Miquel Montequi Hernandez <pau.montequi_at_[hidden]> wrote:You're absolutely right! doing nothing is considerably easier than doing something :PBut afaik that's not the criteria to consider or reject proposals, maybe I'm wrong. Apart from the correct and true fact "If you include a header and write the loop 'like this' you can do the same" is there any other reason to end the discussion?I didn't suggest the discussion should end. But I do think that avoiding the need to include a header is not a good justification for a language change.Many C++ features exist precisely so that interesting and useful things can be done in libraries, instead of pushing more and more features into the core language.A language feature to implicitly create a tuple-like type that can initialize a structured binding would allow you to write this without <tuple>:for (auto [b,e,o] = ?(in, in+size, out); ...)but it would also be usable in other places, so would give more benefit than just alternative syntax for `for` loops.--Pablo Miguel Montequi Hernández.-- 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
Received on 2025-02-10 21:41:51