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.

### 2337. `shared_ptr operator*()` should not be `noexcept`

Section: 20.11.3.6 [util.smartptr.shared.obs] Status: NAD Submitter: Stephan T. Lavavej Opened: 2013-10-05 Last modified: 2017-07-18

Priority: 2

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

View all issues with NAD status.

Discussion:

20.11.1.3.5 [unique.ptr.single.observers]/3: "`pointer operator->() const noexcept;` Requires: `get() != nullptr`."

20.11.3.6 [util.smartptr.shared.obs]/2: "`T& operator*() const noexcept;` Requires: `get() != 0`."

20.11.3.6 [util.smartptr.shared.obs]/5: "`T* operator->() const noexcept;` Requires: `get() != 0`."

Narrow-contract functions should not be `noexcept`.

[2014-02-15 Issaquah]

Issue is contentious, raise to P2.

[2015-02 Cologne]

AM: This ship has sailed. JM: What's the issue? AM: `operator->` has narrow contract and should never have had `noexcept`. DK: Not quite. We explicitly called out that for `shared_ptr` this is fine. You said so in your "narrow contract" paper. GR: This would be a fairly major regression in the design of {`unique`,`shared`}`_ptr` over raw pointers; raw pointer dereferencing is `noexcept`. It's not a performance regression but a usability regression. AM: Do we expect users to query `noexpect` on dereference expressions? Room: Yes. VV: We don't just expect it, we have seen it. JM: Yes, users may be querying something like `noexcept(x->y)` and expect to be checking `y`, but silently end up checking `x->`.

Close as NAD, with explanation from GR. Previous resolution [SUPERSEDED]:

> This wording is relative to N3691.

> 1. In 20.11.1.3 [unique.ptr.single]/1, class template `unique_ptr` synopsis for single objects, change as indicated:

>    >     pointer operator->() const noexcept;

> 2. In 20.11.1.3.5 [unique.ptr.single.observers] change as indicated:

>    >     pointer operator->() const noexcept;

>    > > -3- Requires: `get() != nullptr`.

>    > > -4- Returns: `get()`.

>    > > -?- Throws: Nothing.

>    > > -5- Note: use typically requires that `T` be a complete type.

> 3. In 20.11.3 [util.smartptr.shared]/1, class template `shared_ptr` synopsis, change as indicated:

>    >     T& operator*() const noexcept;
>    >     T* operator->() const noexcept;

> 4. In 20.11.3.6 [util.smartptr.shared.obs] change as indicated:

>    >     T& operator*() const noexcept;

>    > > -2- Requires: `get() != 0`.

>    > > -3- Returns: `*get()`.

>    > > -?- Throws: Nothing.

>    > > -4- Remarks: When `T` is `void`, it is unspecified whether this member function is declared. If it is declared, it is unspecified what its return type is, except that the declaration (although not necessarily the definition) of the function shall be well formed.

>    >     T* operator->() const noexcept;

>    > > -5- Requires: `get() != 0`.

>    > > -6- Returns: `get()`.

>    > > -?- Throws: Nothing.

[2015-03-03, Geoffrey provides rationale]

Rationale:

> It is by design that these members are `noexcept`, and changing that now would be a substantial regression in functionality. These classes were designed to substitute for plain pointers as transparently as possible, so since those operations are effectively `noexcept` on plain pointers, they should be `noexcept` on `unique_ptr` and `shared_ptr` as well. This matters in practice because we expect these members to be used fairly often inside the `noexcept` operator, and such code could be broken by this change. These design considerations override our general policy against `noexcept` for narrow-contract functions.

> It is notable that N3279, which proposed this policy, did not propose striking `noexcept` from these operations. It's not clear if the omission of `operator*` and `operator->` was an oversight, or an intentional reflection of the above considerations. N3279 was based on N3248 by the same authors, which states that:

> > "Most applications of `noexcept` for `unique_ptr` and `shared_ptr` are on functions with wide contracts. However, there are preconditions on the atomic access functions, so these should lose the specification."

Proposed resolution: