Subject: Re: A draft paper to fix the range-based for loop to make it teachable
From: Nicolai Josuttis (nico_at_[hidden])
Date: 2020-11-10 09:58:46
Am 10.11.2020 um 16:08 schrieb Giuseppe D'Angelo via SG20:
> 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,
-- 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
SG20 list run by firstname.lastname@example.org
Older Archives on Google Groups