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.
Section: 12.3 [filesys.ts::directory_entry.obs], 15.12 [filesys.ts::fs.op.exists], 15.16 [filesys.ts::fs.op.is_block_file], 15.17 [filesys.ts::fs.op.is_char_file], 15.18 [filesys.ts::fs.op.is_directory], 15.19 [filesys.ts::fs.op.is_empty], 15.20 [filesys.ts::fs.op.is_fifo], 15.21 [filesys.ts::fs.op.is_other], 15.22 [filesys.ts::fs.op.is_regular_file], 15.23 [filesys.ts::fs.op.is_socket], 15.24 [filesys.ts::fs.op.is_symlink], 15.33 [filesys.ts::fs.op.status], 15.35 [filesys.ts::fs.op.symlink_status], 99 [filesys.ts::fs.op.unique_path] Status: NAD Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2016-08-12
Priority: Not Prioritized
View all other issues in [filesys.ts::directory_entry.obs].
View all issues with NAD status.
Discussion:
Addresses: filesys.ts
exists(const path&) should be noexcept (drop error_code version).
is_*(const path&) should be noexcept (drop error_code version).
status(const path&) should be noexcept (drop error_code version).
symlink_status(const path&) should be noexcept (drop error_code version).
file_status::status() should be noexcept (drop error_code version).
file_status::symlink_status() should be noexcept (drop error_code version).
unique_path(const path&) should be noexcept (drop error_code version).
[2014-02-08: Daniel comments]
unique_path(const path&) cannot be declared as noexcept, because it returns an object during whose construction a memory allocation request may fail, see the rationale provided in 2637.
exists(const path&) and the is_*(const path&) functions cannot be noexcept, because they are specified in terms of status(const path&), which again may throw an exception, which is explicitly described in the Effects (filesystem_error), because the non-throwing function (status(const path&, error_code&)) may fail to satisfy the request. symlink_status(const path&) may throw an exception for similar reasons that status(const path&) could fail. The reference to file_status::status()/symlink_status() looks like a typo to me (there are no such functions in file_status), presumably directory_entry::status()/symlink_status() was meant. In this case I see no reason how these could be marked as noexcept, because these functions all may fail and may throw an exception. Based on this interpretation of the issue discussion I recommend to resolve this issue as NAD.[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.[17 Jun 2014 Rapperswil LWG closes as NAD. Working paper correct as written.]
Proposed resolution: