You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There exist several structs in std::fs which don't appear in fs_err
DirBuilder
Metadata
FileType
Permissions
Of these, the first 2 have methods returning io::Result<_> which would benefit from wrappers.
The last 2 don't have any fallible methods. If fs-err re-exported them, it would add to the "drop-in" quality of the crate. The downside is that if std ever adds fallible methods later, they'd need to be replaced with wrappers in a breaking change.
In the case of Metadata, there already are several APIs which return std::fs::Metadata. When Metadata is wrapped, these should be switched to return the wrapper (breaking change).
The text was updated successfully, but these errors were encountered:
Thinking about it, the re-exports don't add any new forwards-compatibility issues, at least so long as one wants to keep the API consistent and without any surprises.
If FileType were wrapped, then fs_err::DirEntry::file_type would also need to be changed. That's already a breaking change.
Similarly for Permissions, there are two set_permissions functions which take a Permissions struct which would need to be changed.
DirBuilder would certainly make sense to wrap, especially since we already provider a wrapper for tokio::fs::DirBuilder.
It looks like the fallible methods on Metadata only fail if the platform doesn't support the operation - so arguably the path isn't relevant anyway. I dont think its worth a breaking change to wrap it, but I think a re-export is a good idea (and likewise for Permissions and FileType)
There exist several structs in
std::fs
which don't appear infs_err
DirBuilder
Metadata
FileType
Permissions
Of these, the first 2 have methods returning
io::Result<_>
which would benefit from wrappers.The last 2 don't have any fallible methods. If
fs-err
re-exported them, it would add to the "drop-in" quality of the crate. The downside is that ifstd
ever adds fallible methods later, they'd need to be replaced with wrappers in a breaking change.In the case of
Metadata
, there already are several APIs which returnstd::fs::Metadata
. WhenMetadata
is wrapped, these should be switched to return the wrapper (breaking change).The text was updated successfully, but these errors were encountered: