This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 741. Const-incorrect `get_deleter` function for `shared_ptr`

Section: 20.3.2.2.11 [util.smartptr.getdeleter] Status: NAD Submitter: Daniel Krügler Opened: 2007-09-27 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [util.smartptr.getdeleter].

View all issues with NAD status.

Discussion:

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 20.2 [memory] and 20.3.2.2.11 [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 22.10.17.3 [func.wrap.func] or in 22.10.17.3.6 [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 20.2 [memory] and in 20.3.2.2.11 [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.

[ Bellevue: ]

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

Proposed resolution: