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