This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of TS status.
Section: 15.2 [filesys.ts::fs.op.canonical], 15.11 [filesys.ts::fs.op.current_path], 15.27 [filesys.ts::fs.op.read_symlink], 15.36 [filesys.ts::fs.op.system_complete], 15.37 [filesys.ts::fs.op.temp_dir_path], 99 [filesys.ts::fs.op.unique_path], 8.4 [filesys.ts::path.member] Status: TS Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2017-07-30
Priority: Not Prioritized
View all issues with TS status.
Discussion:
Addresses: filesys.ts
all functions with error_code arguments should be noexcept (see canonical, current_path, read_symlink, system_complete, temp_directory_path, unique_path, plus member functions).
[2014-02-03: Stephan T. Lavavej comments:]
The declaration and definition of "recursive_directory_iterator& increment(error_code& ec);" should almost certainly be marked noexcept.
[2014-02-08: Daniel comments]
All functions that return a path value such as canonical, current_path, read_symlink, system_complete, temp_directory_path, unique_path, or any member function returning a path value or basic_string value might legally throw an exception, if the allocator of the underlying string complains about insufficient memory. This is an anti-pattern for noexcept, because the exception-specification includes the return statement of a function and given the fact that the language currently does declare RVO as an optional action, we cannot rely on it.
The Standard is currently very careful not to specify functions as noexcept, if this case can happen, see e.g. std::locale::name(). To the contrary, enforcing them to be noexcept, would cause a similar problem as the unconditional noexcept specifier of the value-returning kill_dependency as denoted by LWG 2236. Basically this requirement conflicts with the section "Adopted Guidelines", second bullet of N3279.[Beman Dawes 2014-02-27]
Issues 2637, 2638, 2641, and 2649 are concerned with signatures which should or should not be noexcept. I will provide unified proposed wording for these issues, possibly in a separate paper.[21 May 2014 Beman Dawes reviewed all functions with error_code& arguments,
and provided proposed wording for the one case found where the above guidelines were not met.
This was the case previously identified by Stephan T. Lavavej.
]
Proposed resolution:
Change 14 Class recursive_directory_iterator [class.rec.dir.itr]:
recursive_directory_iterator& increment(error_code& ec) noexcept;
Change 14.1 recursive_directory_iterator members [rec.dir.itr.members]:
recursive_directory_iterator& increment(error_code& ec) noexcept;