[SG10] New is_aggregate trait

Richard Smith richard at metafoo.co.uk
Sat Apr 8 01:20:00 CEST 2017


On 7 April 2017 at 15:30, Agustín Bergé <agustinberge at gmail.com> wrote:

> On 4/7/2017 7:17 PM, Richard Smith wrote:
> > On 7 April 2017 at 15:00, Agustín Bergé <agustinberge at gmail.com
> > <mailto:agustinberge at gmail.com>> wrote:
> >
> >     On 4/7/2017 5:19 PM, Richard Smith wrote:
> >     > On 30 March 2017 at 19:14, Agustín Bergé <agustinberge at gmail.com
> <mailto:agustinberge at gmail.com>
> >     > <mailto:agustinberge at gmail.com <mailto:agustinberge at gmail.com>>>
> wrote:
> >     >
> >     >     LWG2911 gave us the new `is_aggregate` trait, but no
> feature-test macro.
> >     >     I would like to suggest `__cpp_lib_is_aggregate`. What follows
> is a
> >     >     motivational use case, courtesy of Jonathan Wakely:
> >     >
> >     >          #include <vector>
> >     >          template<typename T, typename... Args>
> >     >          T make(Args&&... args)
> >     >          {
> >     >          #if __cpp_lib_is_aggregate
> >     >              if constexpr (std::is_aggregate_v<T>)
> >     >                  return { std::forward<Args>(args)... };
> >     >              else
> >     >          #endif
> >     >                  return T(std::forward<Args>(args)...);
> >     >          }
> >     >          struct Agg { int i; };
> >     >          int main()
> >     >          {
> >     >              auto v = make<std::vector<int>>(1, 2);
> >     >          #if __cpp_lib_is_aggregate
> >     >              // make<> only supports aggregates if
> std::is_aggregate is
> >     >     available
> >     >              auto a = make<Agg>(1);
> >     >
> >     >
> >     > What does the #else look like here? I'm not yet seeing how this
> feature
> >     > test macro is useful.
> >     >
> >     >          #endif
> >     >          }
> >
> >     There is no #else form here, the example is depicting a program with
> >     decreased functionality. A user of `make` that depends on the feature
> >     simply uses it, and it results in a compilation error when the
> feature
> >     is not present:
> >
> >          int main()
> >          {
> >              auto a = make<Agg>(1);
> >          }
> >
> >     Whereas a user of `make` that does not depend on the feature simply
> does
> >     not use it, and lack of support for the feature does not result in a
> >     compilation error:
> >
> >          int main()
> >          {
> >              auto v = make<std::vector<int>>(1, 2);
> >          }
> >
> >     The feature test macro is needed for the implementation of `make`, in
> >     order to support both use cases.
> >
> >
> > This 'make' seems like a terrible idea, but you've convinced me that
> > people might make use of the feature test macro.
>
> Perhaps we could improve the motivational example then, if needed?
>
> The end goal is not to replace initialization with library machinery,
> but to support aggregate initialization in `make_xxx`/`emplace`
> functions in which initialization is performed by the library on behalf
> of the user, without trapping on `std::initializer_list`.


That still sounds like a terrible idea. C++ does not need yet another form
of initialization. =) But that is not a topic for this list.

Bad idea or not, the above was the motivation for adding the trait, so I
don't think we're going to get a better motivating usage example.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/features/attachments/20170407/74e38d8e/attachment.html 


More information about the Features mailing list