filesystem: Bad mixing of effects in Returns element

[Dani-Hub]

During the Oulo meeting's LWG discussion of some filesystem issues it has been observed that some current Returns elements of fs operations unfortunately mix effects and the actual return specification in a single paragraph.

For example, in [fs.op.file_size] p1 we have

Returns: If !exists(p) || !is_regular_file(p) an error is reported (27.10.7). Otherwise, the
size in bytes of the file p resolves to, determined as if by the value of the POSIX stat structure
member st_size obtained as if by POSIX stat(). The signature with argument ec returns static_- cast<uintmax_t>(-1) if an error occurs.

Here, the part

If !exists(p) || !is_regular_file(p) an error is reported (27.10.7).

would better belong to a separate Effects element (such as in copy or copy_file). Then, the current Returns element could be rephrased as follows:

Returns: The size in bytes of the file p resolves to, determined as if by the value of the POSIX stat structure member st_size obtained as if by POSIX stat(). The signature with argument ec returns static_cast<uintmax_t>(-1) if an error occurs.

A similar problem exists for [fs.op.temp_dir_path] p1, where we have

Returns: An unspecifed directory path suitable for temporary files. An error shall be reported if
!exists(p) || !is_directory(p), where p is the path to be returned. The signature with argument
ec returns path() if an error occurs.

which could be split as follows:

Let p be the path to be returned.

Effects: If !exists(p) || !is_directory(p) an error is reported (27.10.7).

Returns: An unspecifed directory path suitable for temporary files. The signature with argument
ec returns path() if an error occurs.

Is it possible to improve this situation editorially?

[tkoeppe]

@Dani-Hub: I've editorially fixed your editorial issue with some formatting :-)

[burblebee]

@jwakely @zygoloid: can this change be made editorially?

[jensmaurer]

I'd like to point out that resolutions for ~100 NB comments on [filesystems] are in the works. This increases the chance of merge conflicts should we decide to address this editorial issue right now.

[jensmaurer]

Editorial meeting consensus: Fix this editorially after C++17.