https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63192
eracpp <eracpp at eml dot cc> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |eracpp at eml dot cc
--- Comment #5 from eracpp <eracpp at eml dot cc> ---
Bug is still present in trunk (GCC 9.0.0 20180725):
https://wandbox.org/permlink/5uT1YvYSk7OV5IDF
Specifically, GCC does not correctly deduce the type of `e` as a class member
access expression naming the non-static data member for the capture when the
original entity is of reference type.
Given the following context:
int x = 0;
int& l = x;
int&& r = 0;
[=]{
using T = <expr>;
};
Here is a table summarizing GCC's behavior compared to what is correct:
|-----------------------------------------|
| <expr> | Correct | GCC |
|-----------------------------------------|
| decltype(x) | int | int |
| decltype(l) | int& | int& |
| decltype(r) | int&& | int&& |
| decltype((x)) | int const& | int const& |
| decltype((x)) | int const& | int | !!
| decltype((x)) | int const& | int | !!
|-----------------------------------------|
Here are some links to relevant standardese paragraphs:
[expr.prim.lambda.capture]-10 (type of closure member):
http://eel.is/c++draft/expr.prim.lambda.capture#10
[expr.prim.lambda.cpature]-11 (behavior of id-expressions in lambdas):
http://eel.is/c++draft/expr.prim.lambda.capture#11
[expr.prim.id.unqual]-2 (type of unqualified-id expressions in lambdas):
http://eel.is/c++draft/expr.prim.id.unqual#2
