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

### 687. shared_ptr conversion constructor not constrained

Section: 20.3.2.2.2 [util.smartptr.shared.const], 20.3.2.3.2 [util.smartptr.weak.const] Status: CD1 Submitter: Peter Dimov Opened: 2007-05-10 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [util.smartptr.shared.const].

View all issues with CD1 status.

Discussion:

Since all conversions from `shared_ptr<T>` to `shared_ptr<U>` have the same rank regardless of the relationship between `T` and `U`, reasonable user code that works with raw pointers fails with `shared_ptr`:

>     void f( shared_ptr<void> );
>     void f( shared_ptr<int> );

>     int main()
>     {
>       f( shared_ptr<double>() ); // ambiguous
>     }

Now that we officially have `enable_if`, we can constrain the constructor and the corresponding assignment operator to only participate in the overload resolution when the pointer types are compatible.

Proposed resolution:

In 20.3.2.2.2 [util.smartptr.shared.const], change:

> -14- Requires: For the second constructor The second constructor shall not participate in the overload resolution unless `Y*` shall be is implicitly convertible to `T*`.

In 20.3.2.3.2 [util.smartptr.weak.const], change:

>     template<class Y> weak_ptr(shared_ptr<Y> const& r);
>     weak_ptr(weak_ptr const& r);
>     template<class Y> weak_ptr(weak_ptr<Y> const& r);
>     weak_ptr(weak_ptr const& r);
>     template<class Y> weak_ptr(weak_ptr<Y> const& r);
>     template<class Y> weak_ptr(shared_ptr<Y> const& r);

> > -4- Requires: For t The second and third constructors, shall not participate in the overload resolution unless `Y*` shall be is implicitly convertible to `T*`.