Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[willwray]

Bugzilla Link	46704
Version	trunk
OS	All
CC	@apolukhin,@riccibruno,@zygoloid

Extended Description

(Submitting simultaneous requests for each of Clang, GCC and MSVC.
Coordination between vendors will be beneficial for portability.)

Please add a builtin to count the bindings in [dcl.struct.bind].

A structured-bindable object has one of three types T:
Case 1: array type
Case 2: tuple access protocol; tuple_size<T>, tuple_element<I,T>, get<I>
Case 3: else, class types with restricted member data location & access

P2141 "Aggregates are named tuples" proposes automatic tuple-like protocol
for Case 3 types, in particular a generalisation of std::tuple_size.

This request is for a builtin exposing the field count of a Case 3 type
(so can be used to implement P2141's generalized std::tuple_size).

Counting bindings is key; it immediately opens up binding-based reflection.

Specification points (to be discussed & agreed between implementors)

Naming suggestions: __builtin_tuple_size, __builtin_binding_count ?
What value type? What value for an unsupported, non-bindable type?
Should the builtin work for Case 1 array and/or Case 2 tuple-like T?

E.g. given a statement SB<T,N> : auto&& [b1,... bN] = std::declval<T>();
decomposing a T into N bindings:

• If SB<T,N> is well formed then the builtin evaluates to integer constant N
• Else If T is an empty class type then evaluate to 0
• Else evaluate to -1 ?? size_t(-1) ?? false ??

The empty class type exception is a convenience (c.f. std::is_empty<T>)
and future-proofing in case variadic bindings allow the empty pack case.

What about access - should the builtin be sensitive to scope?
(I think not.)(c.f. P0969 DR allowing binding to accessible members.)

Please discuss with other implementors and agree on a portable builtin.
Thanks for your consideration.

GCC ticket https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185
MSVC https://developercommunity.visualstudio.com/idea/1111203/enhancement-please-add-a-builtin-to-count-bindings.html#

[zygoloid]

Instead of the proposed direction, I'd suggest we (and other implementers) prioritize implementation of http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1061r1.html (which is on its way to standardization: cplusplus/papers#294).

Then you can get the number of bindings like this:

auto num_bindings_impl(auto v) {
  auto [...x] = v;
  return std::integral_constant<std::size_t, sizeof...(x)>();
}
template<typename T> constexpr std::size_t num_bindings =
  decltype(num_bindings_impl(std::declval<T>()))::value;

The same technique can be used to extract the types of the bindings, and to handle such intricacies as decltype(x) and decltype((x)) being different, and auto [...x] and auto &[...x] resulting in different behavior (and also lets you control the access context for the query).

The one thing this doesn't give us is a "can an expression of this type be decomposed by structured bindings?" query. It may we worth introducing a dedicated builtin for that (or perhaps for determining whether a class type satisfies the requirements of your case 3 -- the rest of the check can easily be done by the library implementation). That said, based on current EWG discussion it seems plausible that case 3 may soon become the same as "is this a class type?", with the only constraint being on accessibility -- which as you suggested, we likely don't want to take into account.

[willwray]

Thanks Richard; it'd clearly be preferable to expedite P1061 implementations.
I've added your suggestion as a comment on GCC & MSCV tickets.

Would an early-delivered future feature require an opt-in switch?
Can P1061 be default enabled under earlier std flags by DR or otherwise?
A benefit of builtin_count is that it can be available since -std=c++17

My motivation for suggesting a builtin is that it could be a quicker win
(borne of some frustration at lacking reflection features in C++20).
P1306 had issues such that it missed C++20. P1061 may yet hit problems.

P2141 also proposes a std::decomposable<T> predicate trait.
Given a builtin_count, a builtin query is not crucial, just useful.
Lacking builtin_count, and lacking SFINAE on structured bindings,
then a 'decomposable' trait or builtin becomes more crucial to P1061
(perhaps it should be broken out into a separate proposal).

Of the builtin downsides, bikeshedding its name has already reared up.
P1061 is entirely clear of naming roadblocks!

More seriously, the builtin may have a limited shelf-life;
it is strictly less powerful than the language feature that replaces it.
It leaves a legacy feature to support, with edge cases and creep.

Code using the builtin for 'magic' reflection purposes has to delegate to
macro-variadic expansions, only acceptable if there is no better solution.

[Endilll]

P1061R10 has been voted into the draft. Notably, it doesn't work in non-templates.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (4837c776-317b-4adc-a8ef-e2a26bbb71ff)

| | | | --- | --- | | Bugzilla Link | [46704](https://llvm.org/bz46704) | | Version | trunk | | OS | All | | CC | @apolukhin,@riccibruno,@zygoloid |

Extended Description

(Submitting simultaneous requests for each of Clang, GCC and MSVC.
Coordination between vendors will be beneficial for portability.)

Please add a builtin to count the bindings in [dcl.struct.bind].

A structured-bindable object has one of three types T:
Case 1: array type
Case 2: tuple access protocol; tuple_size<T>, tuple_element<I,T>, get<I>
Case 3: else, class types with restricted member data location & access

P2141 "Aggregates are named tuples" proposes automatic tuple-like protocol
for Case 3 types, in particular a generalisation of std::tuple_size.

This request is for a builtin exposing the field count of a Case 3 type
(so can be used to implement P2141's generalized std::tuple_size).

Counting bindings is key; it immediately opens up binding-based reflection.

Specification points (to be discussed & agreed between implementors)

Naming suggestions: __builtin_tuple_size, __builtin_binding_count ?
What value type? What value for an unsupported, non-bindable type?
Should the builtin work for Case 1 array and/or Case 2 tuple-like T?

E.g. given a statement SB<T,N> : auto&& [b1,... bN] = std::declval<T>();
decomposing a T into N bindings:

• If SB<T,N> is well formed then the builtin evaluates to integer constant N
• Else If T is an empty class type then evaluate to 0
• Else evaluate to -1 ?? size_t(-1) ?? false ??

The empty class type exception is a convenience (c.f. std::is_empty<T>)
and future-proofing in case variadic bindings allow the empty pack case.

What about access - should the builtin be sensitive to scope?
(I think not.)(c.f. P0969 DR allowing binding to accessible members.)

Please discuss with other implementors and agree on a portable builtin.
Thanks for your consideration.

GCC ticket https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185
MSVC https://developercommunity.visualstudio.com/idea/1111203/enhancement-please-add-a-builtin-to-count-bindings.html#

[cor3ntin]

@Endilll P1061 is not sufficient for some use cases because you cannot write a concept if you have to introduce a declaration - or, indeed count the number of arguments in any immediate context, so I do believe there are use cases for what is asked