On Fri, Aug 15, 2025 at 12:08:42PM -0400, Jason Merrill wrote:
> > + if (TRAIT_EXPR_KIND (t) == CPTK_STRUCTURED_BINDING_SIZE
> > + && type1 != error_mark_node
> > + && !processing_template_decl)
> > + /* __builtin_structured_binding_size handled separately
> > + to make it SFINAE friendly. */
>
> Hmm, I'm surprised finish_trait_expr isn't already SFINAE-friendly.
I was surprised too. Note, finish_trait_type is SFINAE-friendly.
If it gets changed, the pt.cc hack for this trait can certainly go.
There is another thing, when going through the LLVM test coverage for
this feature, I came to
struct S {};
template <class T> void foo (decltype (__builtin_structured_binding_size (T)))
{}
template void foo <S> (__SIZE_TYPE__);
template <class T> void bar (decltype (__is_trivially_destructible (T))) {}
template void bar <S> (bool);
which clang++ compiles and g++ doesn't (but as can be seen, it is not
specific to this trait, but all the expr traits where the return type is
non-dependent. Seems we try to fold that in temporarily
!processing_template_decl context with dependent argument.
I think I'll file a PR.
> > + RETURN (finish_structured_binding_size (TRAIT_EXPR_LOCATION (t),
> > + type1, complain));
> > RETURN (finish_trait_expr (TRAIT_EXPR_LOCATION (t),
> > TRAIT_EXPR_KIND (t), type1, type2));
> > }
> > --- gcc/testsuite/g++.dg/cpp26/expansion-stmt15.C.jj 2025-08-13
> > 22:10:18.897791624 +0200
> > +++ gcc/testsuite/g++.dg/cpp26/expansion-stmt15.C 2025-08-15
> > 14:12:40.587939623 +0200
> > @@ -27,7 +27,7 @@ foo (int n)
> > int e = 42;
> > d[0] = 42;
> > template for (auto a : A {}) // { dg-warning "'template for'
> > only available with" "" { target c++23_down } }
> > - ; // { dg-error "cannot decompose
> > class type 'A' without non-static data members" "" { target *-*-* } .-1 }
> > + ; // { dg-error "empty structured
> > binding" "" { target *-*-* } .-1 }
>
> I expect you're planning to implement
> https://cplusplus.github.io/CWG/issues/3048.html ?
Eventually yes, I wasn't sure it is needed to do it right away
because it isn't a big deal and the standard is not unclear
or inconsistent in this regard, so until that CWG is voted in (if at all),
we can just follow the standard.
But if you think I should handle it right away, I can do it soon,
it will be dropping that dg-error + removing the error and instead
create the maybe constexpr var instead of the structured binding.
> The patch is OK.
Thanks.
Jakub
