Date: Wed, 1 Jul 2026 10:59:54 +0200
Taking an advance on the request I made in the first reply...
Taking Rainer's example. We want to make sure we call f() in the derived
class with the whole object constructed. We have a few places where we
could do that:
- Base class constructor. Guaranteed wrong, because it'll call base::f();
- Derived1 constructor. Last chance for derived1, but still wrong because
it can't call derived2::f();
- Derived2 constructor. Works for derived2, but now derived1/base don't get
a call to f().
- Just after completing the construction. Works everywhere, but requires
calling it everywhere once. Very error prone.
With this construct we would have a way to attach such a function call to
the end of the in-charge full object constructor. It removes the inability
to generally express the call in the type itself, and it removes the
redundancy and error-prone replication across all call sites. It also
provides an inverse "call this before destroying part of the object" which
is needed in many frameworks to unlink listeners and similar constructs
that rely on the full object still existing.
Depending on how Ruud intends to shape the full proposal, it might provide
a way to make part of the construction or destruction call into a
coroutine. I don't quite see how it would do that, but the use of the
return value(s) of the function(s) are not clear to me, and might allow
this.
I mostly want to see the concrete use cases where this helps out. Who is
this helping, is it a general enough construct to make object construction
more complicated, and is this worth investing the time to fix? Or is it a
niche problem with a sufficient workaround?
Regards,
Peter
On Wed, Jul 1, 2026 at 10:22 AM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Then why not call the respective f() functions from the constructors?
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Rainer Deyke via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mi 01.07.2026 08:26
> *Betreff:* Re: [std-proposals] c++ proposal
> *An:* std-proposals_at_[hidden];
> *CC:* Rainer Deyke <rainerd_at_[hidden]>;
>
>
> On 7/1/26 08:12, Sebastian Wittmeier via Std-Proposals wrote:
> > Making f() virtual is a bit confusing:
> >
> >
> > During construction only the base member function is called. So it could
> be non-virtual as well?
>
> Making f() virtual is the whole point of the example. When called from
> base::base, base::init calls base::f. When called from
> derived1::dervived1, base::init calls derived1::f. When called from
> derived2::dervived2, base::init calls derived2::f.
>
>
> --
> Rainer Deyke - rainerd_at_[hidden]
>
> --
> 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
>
Taking Rainer's example. We want to make sure we call f() in the derived
class with the whole object constructed. We have a few places where we
could do that:
- Base class constructor. Guaranteed wrong, because it'll call base::f();
- Derived1 constructor. Last chance for derived1, but still wrong because
it can't call derived2::f();
- Derived2 constructor. Works for derived2, but now derived1/base don't get
a call to f().
- Just after completing the construction. Works everywhere, but requires
calling it everywhere once. Very error prone.
With this construct we would have a way to attach such a function call to
the end of the in-charge full object constructor. It removes the inability
to generally express the call in the type itself, and it removes the
redundancy and error-prone replication across all call sites. It also
provides an inverse "call this before destroying part of the object" which
is needed in many frameworks to unlink listeners and similar constructs
that rely on the full object still existing.
Depending on how Ruud intends to shape the full proposal, it might provide
a way to make part of the construction or destruction call into a
coroutine. I don't quite see how it would do that, but the use of the
return value(s) of the function(s) are not clear to me, and might allow
this.
I mostly want to see the concrete use cases where this helps out. Who is
this helping, is it a general enough construct to make object construction
more complicated, and is this worth investing the time to fix? Or is it a
niche problem with a sufficient workaround?
Regards,
Peter
On Wed, Jul 1, 2026 at 10:22 AM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Then why not call the respective f() functions from the constructors?
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Rainer Deyke via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mi 01.07.2026 08:26
> *Betreff:* Re: [std-proposals] c++ proposal
> *An:* std-proposals_at_[hidden];
> *CC:* Rainer Deyke <rainerd_at_[hidden]>;
>
>
> On 7/1/26 08:12, Sebastian Wittmeier via Std-Proposals wrote:
> > Making f() virtual is a bit confusing:
> >
> >
> > During construction only the base member function is called. So it could
> be non-virtual as well?
>
> Making f() virtual is the whole point of the example. When called from
> base::base, base::init calls base::f. When called from
> derived1::dervived1, base::init calls derived1::f. When called from
> derived2::dervived2, base::init calls derived2::f.
>
>
> --
> Rainer Deyke - rainerd_at_[hidden]
>
> --
> 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
>
Received on 2026-07-01 09:00:12
