By-copy capture-default causes `const` unless `mutable` despite non-odr-use

[hubert-reinterpretcast]

Bugzilla Link	22604
Version	trunk
OS	All

Extended Description

In the following, it is observed that (consistent with the resolution to DR1472) the appearance of ref in the lambda did not cause the creation of a corresponding member of the closure type since there is no complaint from Clang about the deleted copy constructor.

Since said appearance of ref does not refer to a member of the closure type, it appears that Clang wrong in its complaining about const in the output below. At the same time, adding mutable to the lambda-declarator should not make a difference, but it does with Clang.

SOURCE (<stdin>):

struct A {
   A() = default;
   A(const A &) = delete;
} globalA;

int main() {
   A &ref = globalA, *bar(A &);
   [=]() { bar(ref); };
}

COMPILER INVOCATION:

clang -cc1 -Wno-unused-value -std=c++11 -x c++ -

ACTUAL OUTPUT:

<stdin>:8:16: error: binding of reference to type 'A' to a value of type 'const A' drops qualifiers
   [=]() { bar(ref); };
               ^~~
<stdin>:7:30: note: passing argument to parameter here
   A &ref = globalA, *bar(A &);
                             ^
1 error generated.

EXPECTED OUTPUT:

(Clean compile)

COMPILER VERSION INFO:

clang version 3.7.0 (trunk 229397)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/local/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Selected GCC installation: /usr/local/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Candidate multilib: .;@m64
Selected multilib: .;@m64

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Hubert Tong (hubert-reinterpretcast)

| | | | --- | --- | | Bugzilla Link | [22604](https://llvm.org/bz22604) | | Version | trunk | | OS | All |

Extended Description

In the following, it is observed that (consistent with the resolution to DR1472) the appearance of ref in the lambda did not cause the creation of a corresponding member of the closure type since there is no complaint from Clang about the deleted copy constructor.

Since said appearance of ref does not refer to a member of the closure type, it appears that Clang wrong in its complaining about const in the output below. At the same time, adding mutable to the lambda-declarator should not make a difference, but it does with Clang.

SOURCE (<stdin>):

struct A {
   A() = default;
   A(const A &) = delete;
} globalA;

int main() {
   A &ref = globalA, *bar(A &);
   [=]() { bar(ref); };
}

COMPILER INVOCATION:

clang -cc1 -Wno-unused-value -std=c++11 -x c++ -

ACTUAL OUTPUT:

<stdin>:8:16: error: binding of reference to type 'A' to a value of type 'const A' drops qualifiers
   [=]() { bar(ref); };
               ^~~
<stdin>:7:30: note: passing argument to parameter here
   A &ref = globalA, *bar(A &);
                             ^
1 error generated.

EXPECTED OUTPUT:

(Clean compile)

COMPILER VERSION INFO:

clang version 3.7.0 (trunk 229397)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/local/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Selected GCC installation: /usr/local/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Candidate multilib: .;@<!-- -->m64
Selected multilib: .;@<!-- -->m64

[shafik]

@hubert-reinterpretcast do you believe the analysis is still correct here? Only EDG accepts this: https://godbolt.org/z/j61fTx4az

[hubert-reinterpretcast]

@hubert-reinterpretcast do you believe the analysis is still correct here? Only EDG accepts this: https://godbolt.org/z/j61fTx4az

I believe that the analysis is still correct in the sense that there either is a capture (and a copy that should trigger an error associated with the deleted copy constructor) or there is no capture (and the type of the ref id-expression is non-const A). Which is to say that Clang is definitely wrong here.

The only way to claim that ref has type const A is that there was a capture and the id-expression is an odr-use of the reference (which, because it is usable in constant expressions [*1], it isn't).

The analysis is outdated in that the capture should take place now that odr-usability is the determining factor for whether to capture (GCC and MSVC implement this and do complain about the deleted copy constructor). That still does not change whether the ref id-expression is const or not (because ref cannot be odr-used given the way it is defined).

While Clang exhibits the odd belief that the type of the id-expression is const without having the id-expression designate a captured copy, GCC and MSVC does (erroneously, according to the wording) have the id-expression designate the captured copy: https://godbolt.org/z/KWe9Kdj6h [*2].

I can't advocate that the standard change to mandate the use of the copy regardless of actual odr-use (as a wording issue) because that would cause code-evolution gotchas (in addition to increasing the blast radius of moving a reference into block scope) that adding a = capture default would change which entity gets designated (which is actually what happens with GCC; see code for [*1]).

All in all, I won't mind if someone comes up with a paper to deprecate by-copy captures of references.

[*1]: MSVC gets that wrong: https://godbolt.org/z/qW4b9KThP

struct A {
   int x;
} globalA;

const A *bar(const A &a) { return &a; }

int main() {
   const A &ref = globalA, *bar(const A &);
   auto lambda = []() { return bar(ref); };  // MSVC alone thinks `ref` needs to be captured here.
   ++globalA.x;
   return lambda()->x;
}

[*2]:

struct A {
   int x;
} globalA;

const A *bar(const A &a) { return &a; }

int main() {
   const A &ref = globalA, *bar(const A &);
   auto lambda = [=]() { return bar(ref); };
   ++globalA.x;
   return lambda()->x; // correctly returns 1 with Clang; returns 0 with GCC and MSVC
}

[shafik]

@hubert-reinterpretcast IIUC you think there is an issue here but it is too big a change to be done in core and so this would need to goto evolution for a proper fix.

[hubert-reinterpretcast]

@hubert-reinterpretcast IIUC you think there is an issue here but it is too big a change to be done in core and so this would need to goto evolution for a proper fix.

Yes, and I don't think the fix is obvious or if people would agree that there is an "obvious intent to have and use the copy". If people agree with the latter, then I think the usage without capturing (in [*1] above) should be ill-formed.