Hi,

On 24/02/2022 15:43, Jason McKesson via Std-Proposals wrote:
> That said, I don't think it's a very*useful* idea. It makes
> "potentially invoked" a matter of exactly how you initialize an
> object, which sounds very brittle. One constructor might consider
> certain destructors to be "potentially invoked" while another may not.
> And I'm not sure what any of this would actually purchase you in terms
> of useful functionality.

Language considerations aside, if I understood the issue correctly, I'd
find this change it quite useful.


If you use pimpl extensively/aggressively (like Qt does), you will face
this problem:


// pimpled, in a header
class C {
     std::unique_ptr<class Impl> d;
public:
     C(); // out of line
     ~C(); // out of line
     C(C &&) = default;
};

auto test() {
     C c;
     return c;
}


One would like to have C's move constructor inline (paying for a
function call to move a couple of pointers sounds extremely silly), but
it can't be, because it's still a constructor; so the destructor of `d`
is potentially invoked; and so the compiler has to "emit" such
destructor, but that will fail to compile (in test()) as Impl is incomplete.

But move construction of `unique_ptr` (and thus `C`) cannot throw, so
there's no real need to emit the destructor at all, if it weren't for
the language rules.


The current workaround we have in Qt is extremely silly (declare+export
something like template<> SmartPointer<Impl>::~SmartPointer() [1], so
that the compiler is happy -- even if many compilers realize that it's
not needed and don't even emit the call to it).


My 2 c,


> [1] https://code.woboq.org/qt6/qtbase/src/corelib/tools/qshareddata.h.html#_M/QT_DECLARE_QSDP_SPECIALIZATION_DTOR_WITH_EXPORT

-- 
Giuseppe D'Angelo | giuseppe.dangelo_at_[hidden] | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts