[ Bellevue: ]

Concern this is similar to confusing "pointer to const" with "a constant pointer".

The following issue was raised by Alf P. Steinbach in c.l.c++.mod:

According to the recent draft N2369, both the header memory synopsis of [memory] and [util.smartptr.getdeleter] declare:

template<class D, class T> D* get_deleter(shared_ptr<T> const& p);

This allows to retrieve the pointer to a mutable deleter of a const shared_ptr (if that owns one) and therefore contradicts the usual philosophy that associated functors are either read-only (e.g. key_comp or value_comp of std::map) or do at least reflect the mutability of the owner (as seen for the both overloads of unique_ptr::get_deleter). Even the next similar counter-part of get_deleter - the two overloads of function::target in the class template function synopsis [func.wrap.func] or in [func.wrap.func.targ] - do properly mirror the const-state of the owner.

Possible proposed resolutions:

Replace the declarations of get_deleter in the header <memory> synopsis of [memory] and in [util.smartptr.getdeleter] by one of the following alternatives (A) or (B):

1. Provide only the immutable variant. This would reflect the current praxis of container::get_allocator(), map::key_comp(), or map::value_comp.

   template<class D, class T> const D* get_deleter(shared_ptr<T> const& p);
   

2. Just remove the function.

Alberto Ganesh Barbati adds:

3. Replace it with two functions:

   template <class D, class T> D get_deleter(shared_ptr<T> const&);
   template <class D, class T> bool has_deleter(shared_ptr<T> const&);
   

   The first one would throw if D is the wrong type, while the latter would never throw. This approach would reflect the current praxis of use_facet/has_facet, with the twist of returning the deleter by value as container::get_allocator() do.

Peter Dimov adds:

My favorite option is "not a defect". A, B and C break useful code.