How is it the default in Rust? Like C++, the Rust stdlib gives you both options (std::path::Path::metadata). It boils down to calling stat vs fstat (on posix systems), and it's up to the programmer to make the right choice.
It's about nudging the developer to do the right thing out of the box even if they aren't really aware of all the intricacies. Ergonomic design like this will become a big deal in the future: even if you have very little idea of what you are doing the program actually will be reliable and do the right thing, provided you did not stray too far from the path the language (and the library) nudges you towards.
I agree that that is generally what Rust and the Rust stdlib try to do, but I don't think it holds in this case.
Iterating through a directory generally yields a Path or a DirEntry, both of which have a metadata method readily available, and neither will nudge you to open the file first and then calling metadata on the open file.
which says to me that the Rust version can manifest the bug of the same kind -- there are different time points in which different independent information is checked, and that all the calls correspond to the same opened file handle just can't be assured?
As far as I understand only checking the properties of the opened file via the same file handle is safe for the described kind of bugs, nothing else.
> Metadata request must happen at the different time point than the open of the file and the API as far as I see works on the path, not on the handle
std::fs::File::metadata operates on the open file. If the file is replaced with something else, your open file handle will still refer to the (orphaned) file, and the metadata still reflects its properties.
Then, if C++ could also obtain metadata using the file handle, and the Rust programmer must also take care to call the right "metadata" which even when it does different thing is named completely the same and as the code as written doesn't make obvious if the right overloaded metadata is called, how is Rust better? I.e. how Rust in this example helps me as a reader of the code to be sure if the right metadata function was called?
Call me old fashioned, but only C is more sure to be explicit there as it wouldn't allow two different functions having the same name. If in C++ the corresponding names are also overloaded, both C and C++ "aren't cutting" if the obviousness is not there.
I never claimed that Rust was better in this regard, I merely pointed out that getting metadata from a path is not the only way.
Filesystem handling is not trivial, and some knowledge is required beyond the language itself. I do think that File::metadata and Path::metadata make a nice API together (better than lstat, stat, and fstat).
As for C not allowing two functions with the same name, sure, but then it doesn't have namespaces. In a nicely designed C library for file handling, these functions might well be called std_path_metadata and std_file_metadata, which boils down to the same thing.
You haven't answered my question? How I as a reader see which of the functions with different semantic but named the same was used in the Rust version, and how Rust helps me for that?
No, Rust won't help you with that. On the contrary, Rust has excellent type inference, and in this case the name belongs to a type, which itself is inferred. As a casual reader, you'd have to track the documentation on the preceding calls.
You could do the same in C++, but in Rust it's the default. So...