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.

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.

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 :P
>>
>> But 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.