4 ms·

> 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::

by tijsvd 6y ago

> 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.

acqq 6y ago
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.
- tijsvd 6y ago
  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.
  - acqq 6y ago
    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?
    - tijsvd 6y ago
      Ah right. I misunderstood your question. 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.
      - acqq 6y ago
        That‘s not different from C++ however.

by tijsvd 6y ago

acqq 6y ago

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.

tijsvd 6y ago
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.
- acqq 6y ago
  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?
  - tijsvd 6y ago
    Ah right. I misunderstood your question. 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.
    - acqq 6y ago
      That‘s not different from C++ however.