https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> --- I'm not sure that's worthwhile. Unique ownership is orders of magnitude more common, and lifetime is managed in smaller scopes. Tracking unique ownership within a single function is tractable, and useful. The lifetime can be analyzed for each function in isolation, without interprocedural analysis. Separate functions that correctly manage unique lifetimes compose into larger components which also correctly manage those lifetimes. Analyzing a shared lifetime pointer means also tracking reference counts, and the lifetime typically extends across functions, maybe even across shared library boundaries. Checking for correct code cannot be done for a single function in isolation. If std::shared_ptr is the main example of shared ownership, we don't need to support that in the analyzer, users should not be worrying about its correctness. But users frequently *do* write their own types that manage pointers directly with unique ownership. That's what the analyzer can help with. (In reply to Benjamin Priour from comment #3) > Let's say we only had [[gnu::owner]] for ownership, whether unique or shared. > If so, annotating [[gnu::owner]] would mean "I am becoming A (not THE) owner > of the given resource", i.e. it would always mean "shared" ownership. I agree that this would be a problem, but instead of implying that we need two attributes, I think this implies that we should not try to use [[gsl::owner]] for shared ownership. If you don't try to use it for both, the problem doesn't exist. I would caution against inventing new attributes here. The reason I suggested [[gsl::owner]] is because it is already supported by other analysers and so can be used in portable code.
