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
> <https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2FSepps%2Finheriting-aggregate-initialization&data=04%7C01%7C%7C868f69f474914015b04c08d9f0a16dc0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637805398389707819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=F5czBvYxK0i91y9pzGR8Wku7D2h71kymoTrrGexGJfs%3D&reserved=0>
>
> 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
> <https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=04%7C01%7C%7C868f69f474914015b04c08d9f0a16dc0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637805398389707819%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NFu5pltFUG%2F6VW1kigpF4vSUp0ZJHFdJB0qbUAiaUe8%3D&reserved=0>
>