Date: Sun, 7 Apr 2024 12:52:48 +0000
Hello!
> Your proposal should discuss forwarding:
>
> template <typename T>
> struct Inherit : T {
> template <typename... Args>
> Inherit(Args&&... args) : T{ std::forward<Args>(args)... } {}
> };
In the case of forwarding, you lose the ability to use designated initializers at all. Forwarding constructors prevent direct initialization so makes immovable types constructable.
I'm interested, I just don't know what I would discuss here?
Kind 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 10:00 PM
To: std-proposals_at_[hidden]
Subject: Std-Proposals Digest, Vol 61, Issue 13
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
(Bjorn Reese)
2. Re: Std-Proposals Digest, Vol 61, Issue 12 (David Ledger)
----------------------------------------------------------------------
Message: 1
Date: Sun, 7 Apr 2024 10:38:13 +0200
From: Bjorn Reese <breese_at_[hidden]>
To: David Ledger via Std-Proposals <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Fixing Inheritance of Constructors from
Aggregate bases
Message-ID: <caa34e68-1ff0-9c85-9bcd-2425dfb7fed2_at_[hidden]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Your proposal should discuss forwarding:
template <typename T>
struct Inherit : T {
template <typename... Args>
Inherit(Args&&... args) : T{ std::forward<Args>(args)... } {}
};
------------------------------
Message: 2
Date: Sun, 7 Apr 2024 08:46:26 +0000
From: David Ledger <DavidLedger_at_[hidden]>
To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Std-Proposals Digest, Vol 61, Issue 12
Message-ID:
<SY6P282MB3153FB5A6E992B94EE8508B7FA012_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"
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>
> Your proposal should discuss forwarding:
>
> template <typename T>
> struct Inherit : T {
> template <typename... Args>
> Inherit(Args&&... args) : T{ std::forward<Args>(args)... } {}
> };
In the case of forwarding, you lose the ability to use designated initializers at all. Forwarding constructors prevent direct initialization so makes immovable types constructable.
I'm interested, I just don't know what I would discuss here?
Kind 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 10:00 PM
To: std-proposals_at_[hidden]
Subject: Std-Proposals Digest, Vol 61, Issue 13
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
(Bjorn Reese)
2. Re: Std-Proposals Digest, Vol 61, Issue 12 (David Ledger)
----------------------------------------------------------------------
Message: 1
Date: Sun, 7 Apr 2024 10:38:13 +0200
From: Bjorn Reese <breese_at_[hidden]>
To: David Ledger via Std-Proposals <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Fixing Inheritance of Constructors from
Aggregate bases
Message-ID: <caa34e68-1ff0-9c85-9bcd-2425dfb7fed2_at_[hidden]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Your proposal should discuss forwarding:
template <typename T>
struct Inherit : T {
template <typename... Args>
Inherit(Args&&... args) : T{ std::forward<Args>(args)... } {}
};
------------------------------
Message: 2
Date: Sun, 7 Apr 2024 08:46:26 +0000
From: David Ledger <DavidLedger_at_[hidden]>
To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Std-Proposals Digest, Vol 61, Issue 12
Message-ID:
<SY6P282MB3153FB5A6E992B94EE8508B7FA012_at_[hidden]>
Content-Type: text/plain; charset="us-ascii"
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
*********************************************
------------------------------
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 13
*********************************************
Received on 2024-04-07 12:52:55