Arthur,

You are correct, I should have thought it through a bit more. I was
thinking it might be an issue since it changes the mangling of the function
name, but in this case I really don't think there's any possibility for
breakage.

G

On Sun, Jun 14, 2020 at 5:44 PM Jake Arkinstall via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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).
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>