What does `auto && e` do in range-based for-loops? [duplicate]

Question

Assuming my current rule when programming with range-based loops says

Use for(auto const &e :...) or for(auto &e:...) when possible over for(auto a: ...).

I base this on my own experience and this question for example.

But after reading about the new terse for loops I wonder, should I not replace my & in my rule with &&? As written here this looks like the Meyers' Universal References.

So, I ask myself, should my new rule either be

Use for(auto const &&e :...) or for(auto &&e:...) when possible ...

or does that not always work and therefore should rather be the quite complicated one

Check if for(auto const &&e :...) or for(auto &&e:...) is possible, then consider for(auto const &e :...) or for(auto &e:...), and only when needed do not use references.

Apomorphine

auto && always works. That's why it's "universal". If necessary, the deduced type will be qualified. – Sussna

const auto&& is not a forwarding reference, it's const rvalue reference – Arawn

and the rest is explained in N3853 and What is the advantage of using universal references in range-based for loops? – Arawn

I think it was Herb Sutter in "Back to basics" who said: writing const auto&& is almost always wrong. – Quackery

@Quackery I found the talk slides [github.com/CppCon/CppCon2014/tree/master/Presentations/… but I can not find your reference. He says "for local variables", but I think in "auto for loops" it maay be an exception. Do you have the exact or better reference? – Apomorphine

I could be wrong, maybe it was Scott Meyers in "Type deduction and why you care". – Quackery

@Quackery Well, I'll buy Scott's new book soon anyway. But I have his old C++11 slides and I don't think he mentions it there. I can follow Herbs argument about local variables, but I wonder auto-for is not just an exception then -- or why N3853 seems to disagree. – Apomorphine

@Quackery it was STL during CppCon'14 – Arawn

@PiotrS. No, it is obviously not a "forwarding reference" as in template<class T> void func(T&&). But it seems to me that "reference collapsing rules" do apply here, still. So I assumed one can call this "universal reference", informally. Am I wrong? – Apomorphine

@Quackery Thanks, STL was it, alright. Now I got it, you refer to the const, mainly. I missed that. Of course, thank you. – Apomorphine

@PiotrS. Thank you that is a very important information. I was under a misconception, then. That definitely makes the difference. – Apomorphine

@Apomorphine only auto&&, with no qualifiers, is universal/forwarding reference. None of the following are universal references: const auto&&, volatile auto&&, const volatile auto&&, auto*&&, and so forth... – Arawn

@PiotrS. Cunningham's Law states "the best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." – Quackery

@Apomorphine no, it only states that auto used as a type specifier uses the same rules as template argument deduction procedure, in other words const auto&& = x; is the same as template<class T> void f(const T&& t); f(x);. – Arawn

@PiotrS. Yes, I know, but doesn't exactly your example imply that it behaves like a F/URef? {Damn, how do I move this comment thread to a wiki discussion? :-) } – Apomorphine

@Apomorphine no, because neither T in template<class T> void f(const T&&) is a forwarding reference, nor const auto&& is. The fact that T&& occurs in parameter declaration does not imply it is forwarding reference. Only pure T&& with no qualifiers like const or volatile is forwarding reference, meaning it has to be template<class T> void f(T&&) or auto&&, and never const T&& or const auto&& – Arawn

@PiotrS. Alright, I believe you because you state it so firmly. But I would feel better about it, if you could point me to a reference (no pun intended). – Apomorphine

@towi: §14.8.2.1 [temp.deduct.call]/p3. you seem to still be misleading the difference between auto& and auto&&, as well as const auto& and const auto&&. they have completely different meaning. – Arawn

Answer 1

When and if you should use auto&& in for loops has been explained very nicely by Howard Hinnant here.

This leaves the question what x in

auto &&x = ...expr...

actually is. And it is handled as if there there were a function template definition

template <class U> void f(U&& u);

and the type of x is deduced by the same rules as u [§7.1.6.4.(7)].

This means it is not handled as a RValue Reference, but as a "Universal/Forwarding Reference" -- the "Reference Collapsing Rules" apply.

This also holds for

const auto &&x = ...expr...

as the example in §7.1.6.4.(7) states, at least for const auto &x.

But, as PiotrS says in the questions comments, any qualifiers nullifies the URef-ness:

no, because neither T in template<class T> void f(const T&&) is a forwarding reference, nor const auto&& is. The fact that T&& occurs in parameter declaration does not imply it is forwarding reference. Only pure T&& with no qualifiers like const or volatile is forwarding reference, meaning it has to be template<class T> void f(T&&) or auto&&, and never const T&& or const auto&&

Apomorphine

For Forward reference, it should be template <class U> void f(U&& u); not template <class U> void f(const U& u); – Fazio

"nullifies the URef-ness" is highly misleading... reference collapsing happens for const T&& just as it does for T&&. It is no longer "universal" because half the types in the universe (the ones not const qualified) cannot be matched, but it behaves much the same. – Incondite

@BenVoigt It's not just qualification. A const auto&& declarator or the u in template<class U> void f(const U&& u); can never automatically deduce type from any lvalue. The special rule which makes it valid for a true forwarding reference (and indirectly for the exact type auto&&) no longer applies. – Nobukonoby