If the construct automatically always leads to stack overflow errors, one could - as a third option - disallow it altogether.

Something like a default copy constructor may not be called from a derived class with a parameter passed by value.

So the programmer would have to solve it explicitly. This would be the better alternative than to make a surprising special case.

Can the compiler detect those cases at least most of the time?
 

-----Ursprüngliche Nachricht-----
Von: David wang via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Mi 08.05.2024 08:05
Betreff: [std-proposals] Pass derived object by reference to single parameter delegated templated constructors
An: C++ <std-proposals@lists.isocpp.org>;
CC: David wang <wangjufan@gmail.com>;

On Tue, 7 May 2024 10:36:25 +0200 Sebastian Wittmeier  wrote:

>So in your case, you want to have a reference type deduced (by template argument deduction),

 

>but currently [expr.type]/1 disagrees (https://timsong-cpp.github.io/cppwp/expr.type#1): >If an expression initially has the type ?reference to T? ([dcl.ref], [dcl.init.ref]), the type is >adjusted to T prior to any further analysis.

>The copy constructor is something special (compared to other constructors).
>Why do you want to handle it by a template
>in the first place?

 

Yes, I want to have a reference type deduced, but not  through the template parameter deduction mechanism PR87332.  The template parameter deduction mechanism leads to T, not T&. "template <typename T> base(T x) {}" prevents the compiler from calling the default copy constructor. 

 

There are two ways to prevent it:  modifying function matching rules which seems to confuse the users and breaks existing rules or passing derived objects by reference which is easy to implement and test but violates [expr.type]/1. But this violation is just a special case.

 

Handling it by a template may be the user's choice which is provided by C++. Although users use it correctly, it still leads to bugs.

 

-- 
 Std-Proposals mailing list
 Std-Proposals@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals