Date: Sun, 14 Jun 2020 11:37:53 -0400
On Fri, Jun 12, 2020 at 6:56 PM Filippo Casarin via Std-Proposals <
std-proposals_at_[hidden]> 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"
<https://isocpp.org/std/standing-documents/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
std-proposals_at_[hidden]> 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"
<https://isocpp.org/std/standing-documents/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
Received on 2020-06-14 10:41:18