[llvm-bugs] [Bug 46704] New: Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Jul 13 06:20:39 PDT 2020


https://bugs.llvm.org/show_bug.cgi?id=46704

            Bug ID: 46704
           Summary: Enhancement: Please add a builtin to count bindings in
                    [dcl.struct.bind]
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++17
          Assignee: unassignedclangbugs at nondot.org
          Reporter: wjwray at gmail.com
                CC: blitzrakete at gmail.com, erik.pilkington at gmail.com,
                    llvm-bugs at lists.llvm.org, richard-llvm at metafoo.co.uk

(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#

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200713/289422aa/attachment.html>


More information about the llvm-bugs mailing list