问题
Consider this code (demo):
#include <tuple>
#include <type_traits>
struct Ag{int i;int j;};
using T = std::tuple<int,int>;
using Ar = int[2];
const Ag ag {};
const T t {};
const Ar ar {};
void bind_ag(){
auto [i,j] = ag;
static_assert(std::is_same_v<decltype((i)),int&>);
}
void bind_t(){
auto [i,j] = t;
static_assert(std::is_same_v<decltype((i)),int&>);
}
void bind_ar(){
auto [i,j] = ar;
static_assert(std::is_same_v<decltype((i)),int&>); //For GCC
static_assert(std::is_same_v<decltype((i)),const int&>); //For Clang (and standard?)
}
A structured binding to a copy of a const
c-array are declared const by Clang and non-const by GCC.
The behavior of GCC for c-array is consistent with the behavior observed for aggregate or tuple-like types.
On the other hand from my reading of the standard, I suppose Clang follows what is written. In [dcl.struct.bind]/1 e has type cv A where A is the type of the initializer expression and the cv is the cv-qualifier of the structured binding declaration. And the type of the initializer expression ar
is accordingly to [expr.type]/1 const int[2]
.
What should be expected? My opinion is that Clang follows the standard. On the other hand I feel the intent was that the behaviors for array, aggregate and tuple-like types were equivalent.
回答1:
The wording of the standard in [dcl.struct.bind] says:
If the assignment-expression in the initializer has array type
A
and no ref-qualifier is present,e
has type cvA
and each element is copy-initialized or direct-initialized from the corresponding element of the assignment-expression as specified by the form of the initializer.
We have auto [i,j] = ar;
, ar
has array type const int[2]
, and the wording of the standard makes it clear that e
has type const int[2]
. Thus, per the wording, each binding references the element type - which is const int
. Clang is technically correct.
However, as Richard Smith points out in gcc bug 80649:
I think this is a bug in the standard. The cv-qualifiers of the array type should be discarded, as they would be for any normal auto deduction.
That seems right. When you write auto x = y;
you'd certainly expect x
to not be top-level const
, but here we have a situation where it still is. I don't think there's a Core issue open for this yet, but there should be.
来源:https://stackoverflow.com/questions/53726135/shall-structured-binding-to-a-copy-of-a-const-c-array-be-const