In my understanding of the new C++ standard, the following code should compile. It does not. struct D { D() = default; D(D const &) = default; template<typename ...U> constexpr D(U ...u) {} }; static_assert(std::is_trivial<D>::value, "here"); The problem is the variadic constexpr constructor. I'm guessing here that the problem is that it could also be used as a default constructor, making the type non-trivial. However, I have explicitly defaulted the default constructor, so the variadic constructr should never be considered for 0 arguments. I base the above supposition on the fact that if I add a dummy argument to the variadic as below, it works: struct D { D() = default; D(D const &) = default; template<typename ...U> constexpr D(int, U ...u) // dummy arg, not default c'tor, ok. {} }; static_assert(std::is_trivial<D>::value, "here");
(In reply to comment #0) > In my understanding of the new C++ standard, the following code should compile. > It does not. > > struct D > { > D() = default; > D(D const &) = default; > template<typename ...U> > constexpr D(U ...u) > {} > }; > static_assert(std::is_trivial<D>::value, "here"); With the declarations in this order, it seems easy to fix, in grok_special_member_properties, only set TYPE_HAS_COMPLEX_DFLT to 1 if we didn't already have TYPE_HAS_DEFAULT_CONSTRUCTOR (might have hidden issues, but they are not obvious to me). Now if you put the defaulted constructor after the user-provided variadic one, it becomes much harder, and it looks like we'd have to remember one extra bit of information: the reason why we set TYPE_HAS_COMPLEX_DFLT.
Created attachment 27189 [details] basic patch The patch detects D as trivial. Sadly, on this case: struct A { A()=default; A(int=2); }; it says A is trivial whereas I guess the ambiguity makes it non-trivial. That could be solved for the traits by combining it with is_default_constructible, but it may be problematic to let g++ internally believe that the class is trivially default constructible. For some strange reason, in the case of an ellipsis: struct A { A()=default; A(...); }; it does say: non-trivial. Maybe the whole dance should only be done if the constructor argument is a parameter pack (one that belongs to the function? or several packs?).
(In reply to comment #2) > Sadly, on this case: > struct A { > A()=default; > A(int=2); > }; > it says A is trivial whereas I guess the ambiguity makes it non-trivial. I agree. This is correct assuming http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1363 becomes accepted (There is little doubt for that, though).
Maybe we should be sending patches to the mailing list... But let's add Jason in CC.
We are still missing the implementation of DR1363 (CD3)
This bug has been fixed since GCC 5. If there are outstanding issues as comment #5 suggests that aren't being tracked by any open bugs let's open new issues for them. I'm going to resolve this as fixed. r215771 | jason | 2014-10-01 13:21:01 -0400 (Wed, 01 Oct 2014) | 11 lines PR c++/63362 * class.c (type_has_non_user_provided_default_constructor): Rename from type_has_user_provided_default_constructor, reverse sense. (default_init_uninitialized_part, explain_non_literal_class): Adjust. (check_bases_and_members): Set TYPE_HAS_COMPLEX_DFLT. * call.c (build_new_method_call_1): Adjust. * cp-tree.h: Adjust. * decl.c (grok_special_member_properties): Don't set TYPE_HAS_COMPLEX_DFLT. * init.c (build_value_init_noctor): Don't use type_has_user_provided_default_constructor.
Bug 85723 deals with the problem mentioned in comment 5.