Am 10.11.2020 um 16:08 schrieb Giuseppe D'Angelo via SG20:
> Hi,
>
> On 10/11/2020 10:24, Nicolai Josuttis via SG20 wrote:
>> for years, I have significant problems to teach the range-based for
>> loop, because of the bug that it has undefined behavior when iterating
>> over a reference to a temporary.
>> Thus, I
>> - either have to tell beginners significant constraints in using it
>> - or have to teach all the details why it is broken
>> including references, lifetime extension, universal references
>>
>> Attached is a draft paper to fix the problem.
>> I welcome all feedback and if you want to be a co-author
>> (the more support the paper has the better).
>
> There are a couple of things that I'd like to discuss.
>
> One is if it's worth creating an asymmetry regarding not having similar
> lifetime extensions everywhere else -- for instance, everywhere `auto
> &&` is used. Maybe fixing this problem calls for some other dedicated
> syntax, for instance some attribute to place on top of `auto &&` (or any
> reference declaration, really)?
>
Again, I DO NOT create an asymmetry.
Simply forget about the way we currently specify and explain the
range-based for loop.
WE need this code definition to explain the problem.
Once the problem is goine, we should explain it as a black for
(with rules as of a function call to where you can pass a declaration).


>> [[lifetime_extend]] auto && r = ~~~; // *every* temporary created in
>> ~~~ is lifetime extended until end of scope
>
> Then, the definition of the ranged-based for can be ported to this;
> and/or one could allow the attribute to also be applied to the for as a
> whole, with the implication that it gets applied to the internal
> exposition-only variable.
>
This is a different proposal.
I don't want to propose a full fix.
But you can take the paper as-if I propose to fix the current definition
of the range-base for loop to internally use this attribute.
Feel free, to propose this attribute as an orthogonal paper.

>
> The other is minor and purely educational, and has to do with the (if
> you want) "straightforward" definition of a range-based for loop in
> terms of a "traditional" for loop. An argument that I sometimes use
> towards using the new shiny toys from C++11 and beyond (range-based,
> lambdas) is that they are truly zero cost abstractions; they are
> *defined* to be exactly like the good ol' C++98 for loops using
> iterators, or function objects, just with convenient syntax.
>
> If we give special semantics to the range-based for loop (and only to
> that) then this is no longer true, and one risks objections "this thing
> has embedded hidden magic => the costs are not clear w.r.t. a non-ranged
> loop => I am not going to use it".
>
In the area of compiler optimizations, a traditional for loop
also no longer expands to what we think.
It might for example suddenly introduce vectorization behind the scenes.

>
> Thanks for reading,
>
>
Thanks

-- 
Nicolai M. Josuttis
www.josuttis.de
+49 (0)531 / 129 88 86
+49 (0)700 / JOSUTTIS
Books:
 C++: http://cppstdlib.com, http://cppstd17.com,
      http://tmplbook.com, http://cppmove.com
 SOA: http://soa-in-practice.com