Am 12.11.2020 um 02:17 schrieb Giuseppe D'Angelo:
> Hi,
>
> On 10/11/2020 16:58, Nicolai Josuttis wrote:
>> Feel free, to propose this attribute as an orthogonal paper.
>
> Thanks for the encouragement, this sounds like a major uptake and an
> uphill battle though, and I'm kind of new at the game. :)
>
your're still welcome

>
>>> 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.
>
> I wasn't talking about what wonders compiler optimizations can do, I was
> talking about the "mental model" of what a for loop is for someone
> coming from C or from C++98. One of the arguments to buy in the "fancy
> new toys" (ranged-for, lambdas) is that they're almost literally
> expressed in terms of pre-existing, similar, well established
> constructs. This generally resonates quite well.
>
> (I know and you know that for an optimizing compiler how things are
> "specified" doesn't really matter that much. For people, it does matter.)
>
> On the other hand I have absolutely no idea (yet) how to "sell" the
> mental model of "OK, this is a for, but it's actually specified as a
> *function call* with a for inside!".
>
> Maybe it's just easier to discuss it in terms of an "algorithmic
> function" like for_each, kind of a black box as you said before,
> although the fact that it's a _language_ feature could make it hard to
> approach it like this.
>
I agree,
it is more like for_each(coll).
The only question is how to deal with the other "argument" "auto elem" then.
We pass the collection to iterate over and the declaration for each
element inside the loop.
Yes, that's OK to teach.

Although, people might wonder why the element is a copy, then.
Nevertheless, this is ONLY a performance issue, not undefined behavior.

> Do you have some experience to share?
>
> --
>
> One more technical note. Do you think that with your change proposed,
> one could also think of dropping the deleted rvalue reference overload
> of std::as_const? (And possibly similar other functions.) As far as I
> understand, with your proposed changes, something like
>
>> for (auto & elem : std::as_const(getVector())) { ~~~ }
>
> would now work. Is it worth including it?
>
THAT is an interesting example, thanks.
In principle, you are right, but exactly to avoid problems like the one
above as_const() is deleted for temporary objects:

> template <class T> void as_const(const T&&) = delete;

So, while this could work now, it still would not compile.

Thanks a lot.

Best
  Nico

-- 
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