[ 2017-07 Toronto Thurs Issue Prioritization ]

NAD; Alisdair to provide rationale

The semantics for destroying the deleter and the control-block are unclear. In particular, it is not clear that we guarantee a lack of race conditions destroying the control-block and deleter. Possible race-free implementations might destroy the deleter after running d(p), and before giving up the weak reference held by this shared_ptr; running the destructor for d only when the last weak_ptr is destroyed, potentially at a much later date, but ensuring that d(p) completes before the shared_ptr gives up its weak reference; making a copy of d in the destructor before manipulating the weak count, and then using this copy to run d(p), even while the control-block could be concurrently reclaimed with an expiring weak_ptr in another thread. Note that this may be related to LWG 2751. (Also, see the note in 20.11.2.2.10 p1 [util.smartptr.getdeleter])

Proposed change: Clarify that the shared_ptr weak ownership of the control block is released at the end of the destructor, and not as the destructor begins. Otherwise, the deleter might be destroyed even before the destructor gets to move a copy to call safely.