[Bug c++/96185] New: Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[Bug c++/96185] New: Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[wjwray at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185

            Bug ID: 96185
           Summary: Enhancement: Please add a builtin to count bindings in
                    [dcl.struct.bind]
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wjwray at gmail dot com
  Target Milestone: ---

(Submitting simultaneous requests for each of GCC, Clang 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.

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[wjwray at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185

--- Comment #1 from Will Wray <wjwray at gmail dot com> ---
Clang ticket https://bugs.llvm.org/show_bug.cgi?id=46704

MSVC ticket
https://developercommunity.visualstudio.com/idea/1111203/enhancement-please-add-a-builtin-to-count-bindings.html#

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |11.0
           Severity|normal                      |enhancement

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[wjwray at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185

--- Comment #2 from Will Wray <wjwray at gmail dot com> ---
On the Clang ticket, linked above, Richard Smith comments:

  Instead of the proposed direction, I'd suggest we (and other implementers)
  prioritize implementation of https://wg21.link/p1061r1
  (which is on its way to standardization: 
   https://github.com/cplusplus/papers/issues/294).

My follow-on questions:

Would an early-delivered future feature require an opt-in switch?
Can P1061 be default enabled under earlier std flags by DR or otherwise?

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Will Wray from comment #2)
> Would an early-delivered future feature require an opt-in switch?

The relevant -std switch would be the opt-in.

> Can P1061 be default enabled under earlier std flags by DR or otherwise?

Not as a DR, absolutely not. There is no defect.

It could be supported in non-strict modes as an extension, if the syntax
doesn't conflict with anything a valid program would use.

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Will Wray from comment #0)
> (Submitting simultaneous requests for each of GCC, Clang and MSVC.
>  Coordination between vendors will be beneficial for portability.)

This seems like the wrong approach. If you want something portable that works
in all implementations, propose it for the standard.

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #3)
> Not as a DR, absolutely not. There is no defect.
> 
> It could be supported in non-strict modes as an extension, if the syntax
> doesn't conflict with anything a valid program would use.

Yeah, usually it is something with pedwarn, i.e. accepted in
-std=c++2b/-std=gnu++2b mocdx, a warning in -std=gnu++20/-std=gnu++17 etc. and
an error with -std=c++20/-std=c++17.

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[wjwray at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185

--- Comment #6 from Will Wray <wjwray at gmail dot com> ---
Thanks for the comment on approach Jonathan:

I'd noticed some collaboration and agreement around previous builtins
such as __builtin_bit_cast which is now available in both GCC & Clang
(though with some small inevitable divergence of behaviour).

Clearly Richard's suggestion to prioritize P1061, with such illustrious
co-authorship, is the best solution. I can offer to help on the gcc side.
This is the std way to go.

This request was borne of some frustration; I miss this facility in C++20.
By a hack, Clang happens to support SFINAE on structured binding since v5
- lack of any way to do it in GCC prompted this request.
My thinking was that a builtin can see quicker implementation and adoption
than std features. This builtin _is_ in support of a std proposal.

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[wjwray at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185

--- Comment #7 from Will Wray <wjwray at gmail dot com> ---
Oops, __builtin_bit_cast available in MSVC and Clang (when in GCC?)

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
But __builtin_bit_cast is the compiler magic to support std::bit_cast, it's not
just a non-standard extension. PR 93121 is a request for std::bit_cast in GCC.

[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

[wjwray at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185

--- Comment #9 from Will Wray <wjwray at gmail dot com> ---
An earlier draft had __builtin_tuple_size as the magic behind the P2141
proposed std::tuple_size automagic generalization to Case 3 class types.

There was opposition to that name because it specifically doesn't apply
to tuples so I left the naming open, suggesting __builtin_binding_count
(and, so, requiring consensus on naming for portability...)