Proposed resolution:

Change [util.smartptr.shared] and [util.smartptr.shared.const]:

constexpr shared_ptr();

Change [util.smartptr.weak] and [util.smartptr.weak.const]:

constexpr weak_ptr();

Change [util.smartptr.enab] (2 places):

constexpr enable_shared_from_this();

[ 2009-10 Santa Cruz: ]

NAD EditorialResolved. Solved by N2994.

[ 2009-07-21 Alisdair adds: ]

The feedback from core is that this and similar uses of constexpr constructors to force static initialization should be supported. If there are any problems with this in the working draught, we should file core issues.

Recommend we declare the default constructor constexpr as the issue suggests (proposed wording added).

[ 2009-05-26 Daniel adds: ]

If Alisdair's 2009-05-01 comment is correct, wouldn't that also make constexpr mutex() useless, because this class has a non-trivial destructor? (828)

[ 2009-05-01 Alisdair adds: ]

I don't believe that constexpr will buy anything in this case. shared_ptr/weak_ptr/enable_shared_from_this cannot be literal types as they have a non-trivial copy constructor. As they do not produce literal types, then the constexpr default constructor will not guarantee constant initialization, and so not buy the hoped for optimization.

I recommend referring this back to Core to see if we can get static initialization for types with constexpr constructors, even if they are not literal types. Otherwise this should be closed as NAD.

[ San Francisco: ]

It's not clear to us that you can initialize a pointer with the literal 0 in a constant expression. We need to ask CWG to make sure this works. Bjarne has been appointed to do this.

Core got back to us and assured as that nullptr would do the job nicely here.

Would anyone object to making the default constructor of shared_ptr (and weak_ptr and enable_shared_from_this) constexpr? This would enable static initialization for shared_ptr variables, eliminating another unfair advantage of raw pointers.