747. We have 3 separate type traits to identify classes supporting no-throw operations

Section: 21.3.5.4 [meta.unary.prop] Status: NAD Submitter: Alisdair Meredith Opened: 2007-10-10 Last modified: 2016-01-28

Priority: Not Prioritized

View other active issues in [meta.unary.prop].

View all other issues in [meta.unary.prop].

View all issues with NAD status.

Discussion:

We have 3 separate type traits to identify classes supporting no-throw operations, which are very useful when trying to provide exception safety guarantees. However, I'm not entirely clear on what the current wording requires of a conforming implementation. To quote from has_nothrow_default_constructor:

or T is a class type with a default constructor that is known not to throw any exceptions

What level of magic do we expect to deduce if this is known?

E.g.

struct test{
 int x;
 test() : x() {}
};

Should I expect a conforming compiler to assert( has_nothrow_constructor<test>::value )

Is this a QoI issue?

Should I expect to 'know' only if-and-only-if there is an inline definition available?

Should I never expect that to be true, and insist that the user supplies an empty throw spec if they want to assert the no-throw guarantee?

It would be helpful to maybe have a footnote explaining what is required, but right now I don't know what to suggest putting in the footnote.

(agreement since is that trivial ops and explicit no-throws are required. Open if QoI should be allowed to detect further)

[ Bellevue: ]

This looks like a QoI issue. In the case of trivial and nothrow it is known. Static analysis of the program is definitely into QoI. Move to OPEN. Need to talk to Core about this.

[ 2009-07 Frankfurt: ]

This is QoI.

Move to NAD.

Proposed resolution: