[PATCH] c++, libstdc++, v2: Implement P3856R8 - New reflection metafunction - is_structural_type

[Jason Merrill]

On 3/28/26 2:09 PM, Jonathan Wakely wrote:
> On Sat, 28 Mar 2026 at 17:58, Jakub Jelinek <jakub@redhat.com> wrote:
>>
>> On Sat, Mar 28, 2026 at 05:46:07PM +0000, Jonathan Wakely wrote:
>>>> +ftms = {
>>>> +  name = is_structural;
>>>> +  values = {
>>>> +    v = 202603;
>>>> +    cxxmin = 26;
>>>> +    extra_cond = "__has_builtin(__builtin_is_structural)";
>>>
>>> Hmm, we always use __has_builtin directly in <version>, which I guess
>>> isn't ideal. But it's consistent with the other feature test macros.
>>
>> Guess if we want to change it, we should change all of them.
> 
> Yes, but not for GCC 16.
> 
>>
>>>> --- libstdc++-v3/include/std/meta.jj    2026-03-25 20:19:53.791992428 +0100
>>>> +++ libstdc++-v3/include/std/meta       2026-03-26 17:39:52.979042203 +0100
>>>> @@ -466,6 +466,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>>>       consteval bool is_final_type(info);
>>>>       consteval bool is_aggregate_type(info);
>>>>       consteval bool is_consteval_only_type(info);
>>>> +    consteval bool is_structural_type(info);
>>>
>>> Does this not check the feature test macro because <meta> is coupled
>>> to the compiler, and only works with GCC not Clang, and we know GCC
>>> supports this metafunction?
>>
>> I think at this point is a big unknown what we'll need to do in <meta> for
>> other compilers.
>> Either they decide to use at least mostly similar strategy as GCC (consteval
>> declarations without definitions in <meta>, compiler provides everything;
>> we've tried with Marek to convince them for this path a few weeks ago),
>> or they decide to put a lot of stuff in the header and use some builtins in
>> there (that is what is on Dan's clang fork and some clang developers prefer
>> that; in that case I think cleanest would be #include <bits/clang_meta.h>
>> or something similar to only load up large chunks of clang specific code
>> when compilining by that compiler), something else.
>>
>> But sure, if you want a FTM around it (it would need to be the __glibcxx_*
>> one) to make it clear that it is a metafn added for non-reflection paper
>> with its own FTM, I can add it here and in std.cc.in.
> 
> Yes please, I think it might be helpful to mark it as being added
> separately from the rest of the reflection metafunctions.
> 
> Thanks. The library parts are OK with that.

The compiler parts are OK.

In discussion of P3856, did anyone suggest adding arrays of structural 
type to "structural type"?  It seems cumbersome to need to write 
structural-or-array-of-same everywhere.  Or perhaps that's a familiar 
dance for other traits.

Jason