1179. Probably editorial in [structure.specifications]

Section: [structure.specifications] Status: NAD Editorial Submitter: Robert Klarer Opened: 2009-07-21 Last modified: 2016-01-28 10:19:27 UTC

Priority: Not Prioritized

View other active issues in [structure.specifications].

View all other issues in [structure.specifications].

View all issues with NAD Editorial status.


While reviewing 971 I noted that [structure.specifications]/7 says:

-7- Error conditions specify conditions where a function may fail. The conditions are listed, together with a suitable explanation, as the enum class errc constants (19.5) that could be used as an argument to function make_error_condition (

This paragraph should mention make_error_code or the text "that could be used as an argument to function make_error_condition (" should be deleted. I believe this is editorial.

[ 2009-07-21 Chris adds: ]

I'm not convinced there's a problem there, because as far as the "Error conditions" clauses are concerned, make_error_condition() is used by a user to test for the condition, whereas make_error_code is not. For example:

void foobar(error_code& ec = throws());

Error conditions:

permission_denied - Insufficient privilege to perform operation.

When a user writes:

error_code ec;
if (ec == errc::permission_denied)

the implicit conversion errc->error_condition makes the if-test equivalent to:

if (ec == make_error_condition(errc::permission_denied))

On the other hand, if the user had written:

if (ec == make_error_code(errc::permission_denied))

the test is now checking for a specific error code. The test may evaluate to false even though foobar() failed due to the documented error condition "Insufficient privilege".

[ 2009 Santa Cruz: ]

NAD Editorial.

What the WP says right now is literally true: these codes can be used as an argument to make_error_condition. (It is also true that they can be used as an argument to make_error_code, which the WP doesn't say.) Maybe it would be clearer to just delete "that could be used as an argument to function make_error_condition", since that fact is already implied by other things that we say. We believe that this is editorial.

Proposed resolution: