This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/66672] std::is_same wrong result for captured reference value inside a lambda
- From: "anders at knatten dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 15 Mar 2018 20:23:18 +0000
- Subject: [Bug c++/66672] std::is_same wrong result for captured reference value inside a lambda
- Auto-submitted: auto-generated
- References: <bug-66672-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66672
--- Comment #4 from Anders Schau Knatten <anders at knatten dot org> ---
Update: There's a related issue with Clang, in which Richard Smith makes a good
argument: https://bugs.llvm.org/show_bug.cgi?id=35423#c2
He refers to http://eel.is/c++draft/expr.prim.id.unqual#2.sentence-2, of which
I was previously unaware, which seems to cover what was previously covered by
§5.1.2¶18 in C++11. It says:
"If the entity is a local entity and naming it from outside of an unevaluated
operand within the declarative region where the unqualified-id appears would
result in some intervening lambda-expression capturing it by copy
([expr.prim.lambda.capture]), the type of the expression is the type of a class
member access expression ([expr.ref]) naming the non-static data member that
would be declared for such a capture in the closure object of the innermost
such intervening lambda-expression."
If I read that passage correctly, it says that "even if decltype doesn't
odr-use the identifier, and thus it isn't actually captured, the type of the
expression is still as if it had been captured."
So I now believe my previous comment was wrong, and that gcc is wrong both
according to C++11 and the current draft.