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. :)


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

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?
Thank you,
-- 
Giuseppe D'Angelo | giuseppe.dangelo_at_[hidden] | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts