Proposed resolution:

This wording is relative to the FDIS.

1. Change [iostreams.base.overview], header <ios> synopsis as indicated:

   #include <iosfwd>
   namespace std {
     […]
     error_code make_error_code(io_errc e) noexcept;
     error_condition make_error_condition(io_errc e) noexcept;
     const error_category& iostream_category() noexcept;
   }
   

2. Change the prototype declarations in [error.reporting] as indicated:

   error_code make_error_code(io_errc e) noexcept;
   

   -1- Returns: error_code(static_cast<int>(e), iostream_category()).

   error_condition make_error_condition(io_errc e) noexcept;
   

   -2- Returns: error_condition(static_cast<int>(e), iostream_category()).

   const error_category& iostream_category() noexcept;
   

   -3- Returns: A reference to an object of a type derived from class error_category.

   -4- The object’s default_error_condition and equivalent virtual functions shall behave as specified for the class error_category. The object’s name virtual function shall return a pointer to the string "iostream".

[ 2013-09-29, Chicago ]

Apply to Working Paper

[ 2013-04-20, Bristol ]

Unanimous.

Resolution: move to tentatively ready.

In <system_error> we have:

const error_category& generic_category() noexcept;
const error_category& system_category() noexcept;

In <future> we have:

const error_category& future_category() noexcept;

But in <ios> we have:

const error_category& iostream_category();

Is there any reason that iostream_category() is not declared with noexcept or is this an oversight?

Daniel:

This looks like an oversight to me. We made the above mentioned changes as part of noexcept-ifying the thread library but iostream_category() was skipped, so it seems to be forgotten. There should be no reason, why it cannot be noexcept. When doing so, we should also make these functions noexcept (similar to corresponding overloads):

error_code make_error_code(io_errc e);
error_condition make_error_condition(io_errc e);

Suggested wording provided by Daniel.