Proposal: Enable std::shared_ptr to delete objects with protected/private destructors via friendship

[davitkalantaryan]

Hi all,

I’ve prepared a proposal to improve std::shared_ptr so that it can delete objects with protected or private destructors — provided that the class declares friend class std::shared_ptr<T>. Currently, this does not work, because the actual deletion is handled by internal helpers or lambdas that are not considered friends, even if shared_ptr<T> itself is.

This limitation weakens encapsulation and safety patterns. In a real project, I experienced this firsthand: forgetting that a particular object was managed by shared_ptr, I deleted it manually — which led to hard-to-trace crashes. Declaring the destructor as protected was meant to prevent such mistakes, but it didn’t help, because shared_ptr was unable to perform deletion due to access restrictions.

---

What This Proposal Suggests

• If shared_ptr<T> is declared a friend of T, it should be allowed to delete T directly — not via an inaccessible internal deleter.
• This change enables safer ownership enforcement without requiring boilerplate custom deleters.
• (Optional) Introduce a mechanism to observe reference count changes via a callback, useful for debugging and UI synchronization.

---

References

• Medium article:
  https://medium.com/@davit.kalantaryan1980/why-std-shared-ptr-should-support-classes-with-protected-destructors-ea4dee6a377d

• Demo repository (fails to compile):
  https://github.com/davitkalantaryan/demo-cpputils/blob/master/src/tests/main_std_shared_ptr_friend_error.cpp

• Working implementation:
  sharedptr.hpp

• Full proposal document (DOCX):
  https://github.com/user-attachments/files/20195117/SharedPtr_Proposal_DavitKalantaryan_FINAL.docx

---

@jwakely — since you've contributed significantly to shared_ptr and libstdc++, I would be very grateful for your input on this topic. If you find the idea worthwhile, I’d also greatly appreciate your consideration as a potential sponsor for WG21 discussion. Of course, I welcome feedback from all reviewers as well.

Thank you in advance!
— Davit Kalantaryan

---

Appendix: Clarification After Community Feedback

Following early discussions (particularly on Reddit), I’ve added this clarification to the proposal:

Many developers rightly point out that if a smart pointer manages an object’s lifetime, manual deletion should never occur. While that’s true in principle, large and evolving codebases make mistakes inevitable. That’s why C++ provides access specifiers like private and protected: not because developers are careless, but because the compiler helps enforce correct usage.

Saying “just don’t delete manually” is similar to saying “we don’t need private or protected; developers should just avoid calling the wrong function.” But we do have those tools — to make incorrect usage harder, not merely discouraged.

This proposal aims to bring the same level of safety to destructor access. If shared_ptr<T> is a friend, it should be allowed to delete T, just like any other friend.

[jensmaurer]

This issue tracker is for editorial issues related to the C++ standard only; see https://github.com/cplusplus/draft/wiki/How-to-tell-if-an-issue-is-editorial .

This write-up appears to present a proposal, not an editorial issue; please see https://isocpp.org/std/submit-a-proposal for hints on how to submit these.

[jwakely]

I'm pretty sure you can already do this by using std:: allocate_shared and making the allocator a friend.