On Fri, Jun 12, 2020 at 6:56 PM Filippo Casarin via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

With the current c++20 standard the following code

#include <array>
struct S {
std::array<int, 4> arr;

void foo() {
static_assert(arr.size());
}
};

generate this error

main.cpp: In member function ‘void S::foo()’:
main.cpp:7:31: error: non-constant condition for static assertion
7 | static_assert(arr.size());
| ~~~~~~~~^~
main.cpp:7:31: error: use of ‘this’ in a constant expression

This would work if std::array::size would be static, also I don't think any old code would break for this change.

There is always some old code that would break. :) In this case, the obvious thing that would change is the type of `&std::array<int,10>::size`—

template<class T>

void f(size_t (T::*MFP)() const) { }

int main() {

f(&std::array<int,10>::size); // oops

using A = std::array<int, 10>;

std::vector<A> v;

auto sizes_of_v = std::move(v) | std::ranges::transform(&A::size); // oops

}

However, standing document SD-8 "Standard Library Compatibility" indicates (obliquely, by implication) that &std::array<int,10>::size is not in the set of things that the Committee promises not to break. (Because it uses the method name `size` without actually invoking the method.)

So I see no technical reason that the Committee would refuse a request to make `size` into a static member function.

However, you do also have to look at cost versus benefit; I suspect that the cost (of requiring vendors to make the change; more importantly, of requiring WG21 members to look at the proposal) would outweigh the minor benefit in this case.

Re other comments in this thread:

- connor: The expression `a.size()` continues to compile even when .size() is a static member function.

- Gašper: Since `array` is a class template, I'm not seeing any specific possibility for ABI breakage here. Did you have something specific in mind?

my $.02,

–Arthur