constexpr std::array with static_assert

Question

#include <iostream>
#include <array>

int main(int argc, char **argv) {
    constexpr const std::array<int, 2> arr {{ 0, 1 }};
    constexpr const int arr2[] = { 0, 1};

    static_assert(arr[0] == arr2[0], "asdf");
    static_assert(arr[1] == arr2[1], "asdfasdf");

    return 0;
}

When compiled with gcc 4.8.2 and 4.9.1 using g++ test.cpp --std=c++11, the compilation succeeds. When compiled with clang 3.4 and 3.5 using clang++ test.cpp --std=c++11 however, the compilation fails:

test.cpp:8:16: error: static_assert expression is not an integral constant expression
        static_assert(arr[0] == arr2[0], "asdf");
                      ^~~~~~~~~~~~~~~~~
test.cpp:8:16: note: non-constexpr function 'operator[]' cannot be used in a constant expression

So my question is, which compiler is "right" in the sense of being compliant with C++11? And, if clang is correct, then why is std::array's operator[] not constexpr capable? Isn't that rather one of the things that std::array was supposed to help resolve?

Answer 1

It looks like clang is correct, operator [] is not a constexpr in C++11 but is a constexpr in C++14

constexpr const_reference operator[]( size_type pos ) const; (since C++14)

so compiling with -std=c++14 should work though (see it live).

In the C++11 draft standard section 23.3.2.1 Class template array overview has the following for operator []:

reference operator[](size_type n);
const_reference operator[](size_type n) const;

while the C++14 draft standard has the following:

reference operator[](size_type n);
constexpr const_reference operator[](size_type n) const;
^^^^^^^^^

Update

Draft standard N3485 which came after C++11, contains fixes an enhancements to C++11. It contains a constexpr version of operator []. If this was part of a defect report then gcc would be correct and this seems plausible considering clang 3.6.0 also accepts the program in C++11 mode.

Update 2

I found the document that introduced the changes, N3470 and since I can not find any defect reports on this specific issue then this seems like an enhancement and therefore should not be part of C++11.