Hello!

> To that I have a few notes:
> 1. `using` keyword shouldn't be necessary

This is not a proposal to be the sole means of brace elision allowing designated initializers, even though it does allow that. A proposal to allow for designated initializers with brace elision could co-exist with this.

> 2. you shouldn't be allowed to do this if data is private. On your example you are changing private data, this is an anti-pattern, should not be allowed. Sure, you made the implicit constructor public, but the data members are not public.

`using T::T` can already be used to expose private data/methods:

    struct Foo : private Bar
    {
          using Bar::Method; // Is now public.
    };

Whether or not I agree with your assertion, we cannot retroactively change this.

> I also thing that the following:
> Bar var{1, 2, 3};
> Is an abomination of the language and it should die, designated initializer is superior and I think should be used preferentially, if the proposal skips this I think it would be for the better.

I generally prefer designated initializers too, but it's just not always the right choice, take `std::array` or aggregate tuples, if we did enforce designated initializers you'd see:

    auto object = std::array{ ._M_instance = {1, 2, 3, 4, 5, 6} };

Additionally, deprecating non-designated initializers in general would break a huge number of libraries targeting earlier C++ versions and hurt adoption of new standards.

Regards,
David Ledger

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of std-proposals-request_at_[hidden]
Sent: Sunday, April 7, 2024 5:21 PM
To: std-proposals_at_[hidden]
Subject: Std-Proposals Digest, Vol 61, Issue 12

Send Std-Proposals mailing list submissions to
        std-proposals_at_[hidden]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
or, via email, send a message with subject or body 'help' to
        std-proposals-request_at_[hidden]

You can reach the person managing the list at
        std-proposals-owner_at_[hidden]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Std-Proposals digest..."


Today's Topics:

   1. Re: Fixing Inheritance of Constructors from Aggregate bases
      (David Ledger)
   2. Re: Fixing Inheritance of Constructors from Aggregate bases
      (Tiago Freire)


----------------------------------------------------------------------

Message: 1
Date: Sun, 7 Apr 2024 06:24:10 +0000
From: David Ledger <DavidLedger_at_[hidden]>
To: Zhihao Yuan <zy_at_[hidden]>, "std-proposals_at_[hidden]"
        <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Fixing Inheritance of Constructors from
        Aggregate bases
Message-ID:
        <SY6P282MB3153730A5216949AF1C21BD1FA012_at_[hidden]>

Content-Type: text/plain; charset="utf-8"

Hello!

Neither option A nor B would allow for designated initializers being using for non-inherited objects.

Option B proposes behaviour consistent with inheritance of constructors (for example):

    struct Foo
    {
        Foo(int, int);
    };

    struct Bar : Foo
    {
        using Foo::Foo;
        int a = 0;
    };

It would not be possible to do this:

    auto bar = Bar{1, 2, 3};

Or this:

    auto bar = Bar{Foo{1, 2}, 3};

Once the `using Foo::Foo` is applied, all data members and base classes are default initialized (except the base which the constructor was inherited from).

Kind regards,
    David Ledger

From: Zhihao Yuan <zy_at_[hidden]>
Sent: Sunday, April 7, 2024 4:00 PM
To: std-proposals_at_[hidden]
Cc: David Ledger <DavidLedger_at_[hidden]>
Subject: Re: [std-proposals] Fixing Inheritance of Constructors from Aggregate bases

If I have

    struct Foo { int a, b; }
    struct Bar : Foo { using Foo::Foo; int c; }

Can I do

    auto bar = Bar{.a = 1, .b = 2, .c = 3}; // ?

if so, I think it might remove some concerns over Designated-initializers for Base Classes (open-std.org)<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2287r2.html>

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________
On Saturday, April 6th, 2024 at 9:36 PM, David Ledger via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
Hello everybody!!
Right now, this will not compile:
struct Foo { int a, b; }
struct Bar : Foo { using Foo::Foo; }
auto bar = Bar{1, 2}; // ERROR
Which is confusing and unintuitive. This paper proposes an improvement to this behaviour.
https://seppeon.gitlab.io/cpp-proposals/inheritance-of-aggregate-initialization.html#_abstract
Regards,
David Ledger
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
Message: 2
Date: Sun, 7 Apr 2024 07:20:30 +0000
From: Tiago Freire <tmiguelf_at_[hidden]>
To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>,
        Zhihao Yuan <zy_at_[hidden]>
Cc: David Ledger <DavidLedger_at_[hidden]>
Subject: Re: [std-proposals] Fixing Inheritance of Constructors from
        Aggregate bases
Message-ID:
        <AS2P194MB21874CE1FEC96FD196BB8FFFC2012_at_[hidden]>
Content-Type: text/plain; charset="utf-8"
In many instances I wished I was able to do this:
struct Foo
{
   int a;
   int b = 0;
};
struct Bar : public Foo
{
  int c;
};
Bar var{.a = 1, .b=2, .c=3}
That?s it, none of them define explicit constructors, I just want to initialize data in my struct, I should be able to do it.
To that I have a few notes:
1. ?using? keyword shouldn?t be necessary 2. you shouldn?t be allowed to do this if data is private. On your example you are changing private data, this is an anti-pattern, should not be allowed. Sure, you made the implicit constructor public, but the data members are not public.
I also thing that the following:
Bar var{1, 2, 3};
Is an abomination of the language and it should die, designated initializer is superior and I think should be used preferentially, if the proposal skips this I think it would be for the better.
My 2c
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of David Ledger via Std-Proposals
Sent: Sunday, April 7, 2024 08:24
To: Zhihao Yuan <zy_at_[hidden]>; std-proposals_at_[hidden]
Cc: David Ledger <DavidLedger_at_[hidden]>
Subject: Re: [std-proposals] Fixing Inheritance of Constructors from Aggregate bases
Hello!
Neither option A nor B would allow for designated initializers being using for non-inherited objects.
Option B proposes behaviour consistent with inheritance of constructors (for example):
    struct Foo
    {
        Foo(int, int);
    };
    struct Bar : Foo
    {
        using Foo::Foo;
        int a = 0;
    };
It would not be possible to do this:
    auto bar = Bar{1, 2, 3};
Or this:
    auto bar = Bar{Foo{1, 2}, 3};
Once the `using Foo::Foo` is applied, all data members and base classes are default initialized (except the base which the constructor was inherited from).
Kind regards,
    David Ledger
From: Zhihao Yuan <zy_at_[hidden]<mailto:zy_at_[hidden]>>
Sent: Sunday, April 7, 2024 4:00 PM
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Cc: David Ledger <DavidLedger_at_[hidden]<mailto:DavidLedger_at_[hidden]>>
Subject: Re: [std-proposals] Fixing Inheritance of Constructors from Aggregate bases
If I have
    struct Foo { int a, b; }
    struct Bar : Foo { using Foo::Foo; int c; }
Can I do
    auto bar = Bar{.a = 1, .b = 2, .c = 3};  // ?
if so, I think it might remove some concerns over Designated-initializers for Base Classes (open-std.org)<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2287r2.html>
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________
On Saturday, April 6th, 2024 at 9:36 PM, David Ledger via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
Hello everybody!!
Right now, this will not compile:
struct Foo { int a, b; }
struct Bar : Foo { using Foo::Foo; }
auto bar = Bar{1, 2}; // ERROR
Which is confusing and unintuitive. This paper proposes an improvement to this behaviour.
https://seppeon.gitlab.io/cpp-proposals/inheritance-of-aggregate-initialization.html#_abstract
Regards,
David Ledger
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
Subject: Digest Footer
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
------------------------------
End of Std-Proposals Digest, Vol 61, Issue 12
*********************************************