Date: Sun, 14 Jun 2020 17:44:12 +0100
I see the general issue is in trying to access values that are known but
are otherwise inaccessible. Arrays having tuple_size is a good workaround
for this specific case, but I'm sure that there are similar issues that
have no such solution.
I'd not be in favour of making array::size() static. It seems that it was
chosen in order to provide a common container interface, and that's a
design consideration that's rather common in the standard library. The
justification for that, however annoying, hasn't disappeared.
If it's really necessary I'd have a new static method static_size(), or
have the ability to have static methods that provide a static interface and
a non-static interface. That seems like a big sledgehammer to crack this
particular nut, though.
Honestly I'd sooner see advances to make the more general problem a
non-issue (perhaps with the help of [N4433], [P1996], not to mention the
smorgasbord of functionality that reflection will give us).
are otherwise inaccessible. Arrays having tuple_size is a good workaround
for this specific case, but I'm sure that there are similar issues that
have no such solution.
I'd not be in favour of making array::size() static. It seems that it was
chosen in order to provide a common container interface, and that's a
design consideration that's rather common in the standard library. The
justification for that, however annoying, hasn't disappeared.
If it's really necessary I'd have a new static method static_size(), or
have the ability to have static methods that provide a static interface and
a non-static interface. That seems like a big sledgehammer to crack this
particular nut, though.
Honestly I'd sooner see advances to make the more general problem a
non-issue (perhaps with the help of [N4433], [P1996], not to mention the
smorgasbord of functionality that reflection will give us).
Received on 2020-06-14 11:47:30