std::array operator==() isn't constexpr - shouldn't it be?

[eya...@technion.ac.il]

I recently asked the following question (originally on StackOverflow):

It's very natural to want to compare std::array's at compile time; and its operator==() is obviously constexpr'able. Yet - it isn't marked constexpr. Is this intentional or an oversight? And - what's the reason it was left that way (apparently in C++17 as well)?

 I was told that this was probably an oversight (follow the SO link for the detailed answer), and that I should consider filing a defect report.

Is it indeed an oversight? Should I file a defect report?

Perhaps I should mention I've noticed that the libstdc++ 5 implementation uses std::equal(), which is also not constexpr, making me second-guess my assumptions somewhat.

Eyal

PS - A complaint about this issue can also be found in the Boost Hana documentation introduction section.

[Daniel Krügler]

2017-08-20 21:23 GMT+02:00 <eya...@technion.ac.il>:
>
> I recently asked the following question (originally on StackOverflow):
>
>> It's very natural to want to compare std::array's at compile time; and its
>> operator==() is obviously constexpr'able. Yet - it isn't marked constexpr.
>> Is this intentional or an oversight? And - what's the reason it was left
>> that way (apparently in C++17 as well)?
>
>
> I was told that this was probably an oversight (follow the SO link for the
> detailed answer), and that I should consider filing a defect report.
>
> Is it indeed an oversight? Should I file a defect report?
>
> Perhaps I should mention I've noticed that the libstdc++ 5 implementation
> uses std::equal(), which is also not constexpr, making me second-guess my
> assumptions somewhat.

Actual, this is not just an example for a specific implementation, but
this is the specified operational semantics of == of all containers,
see Table 83 — Container requirements.

I recommend to wait for the approval of P0202, whose most recent
revision is this one, which would clearly simplify the specification:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0202r1.html

At the current state, I would not consider the current situation as a
defect, this is a feature request and without constexpr support from
<algorithm> harder to argue for.

I recommend to contact the author of p0202 who is also the author of

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html

which added a great extend of constexpr to std::array and some other
library components. You might want to coauthor a proposal adding more
constexpr for std::array, including ==.

- Daniel

[Thiago Macieira]

On Sunday, 20 August 2017 13:04:23 PDT Daniel Krügler wrote:
> I recommend to wait for the approval of P0202, whose most recent
> revision is this one, which would clearly simplify the specification:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0202r1.html

As that paper says, adding constexpr to certain functions may imply
performance regressions.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center