Hi David,

I have experience with writing proposals about aggregate initialisation and getting them into the standard. So I can help you put this together as a proper proposal. I think your proposed change would be a good fix.

Cheers,
Timur

> On 27 Mar 2022, at 07:08, David Ledger via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 
> Haven't had any further followup with this, how shall I proceed?
>
> On 16/02/2022 3:37 am, Gašper Ažman wrote:
>> Anyone volunteer to lead the new author towards getting a paper number and submit the paper to the system? I'm busy.
>>
>> On Tue, Feb 15, 2022 at 3:50 PM Ville Voutilainen via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>> On Tue, 15 Feb 2022 at 17:40, David Ledger via Std-Proposals
>>> <std-proposals_at_[hidden]> wrote:
>>> >
>>> > Gday all!
>>> >
>>> > In generic contexts it can be desirable to inherit the constructors of a base class. Currently, this leads to broken code when the base class is an aggregate, as it is no longer possible to initialize the aggregate base's members.
>>> >
>>> >
>>> > An example:
>>> >
>>> > ---
>>> > struct A { A(int a, int b, int c){} };
>>> >
>>> > struct B { int a, b, c; };
>>> >
>>> > template <typename T>
>>> > struct N : T { using T::T; };
>>> >
>>> > N<A> a{1, 2, 3}; // current: ok, inherits A::A
>>> >
>>> > N<B> b{1, 2, 3}; // current: error, no constructor to inherit(and `N<B>` is now, not an aggregate)
>>> > // proposed: ok, elides the braces, and aggregate constructs
>>> >
>>> > N<B> c{.a = 1, .b = 2, .c = 3}; // current: error, designated initializers cannot be used with a non-aggregate type 'Bar'
>>> > // proposed: ok, Foo's a, b, and c are initialized via the designated initalizers.
>>> > ---
>>> >
>>> > Proposal is here:
>>> > ---
>>> > https://gitlab.com/Sepps/inheriting-aggregate-initialization
>>>
>>> So, the problem is that a using-declaration that inherits constructors
>>> renders a type a non-aggregate even if it inherits
>>> an aggregate?
>>>
>>> At the first glance, "Ignore using T::T for aggregates completely."
>>> seems like a good idea to me. And in general, I agree that this would
>>> be a good fix to make, not 100% of which approach is the best. The
>>> "ignore" option seems like it does all the right things, afaics.
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals