Description
Resume
I'm personally confused about the existence of
fs::Metadata::is_dir()
and
fs::Metadata::is_file()
At the same time that we DON'T have a
fs::Metadata::is_symlink()
It doesn't make a lot of sense
Context before we go:
fs::Metadata::file_type()
returns a fs::FileType
fs::FileType
just contains 3 functions, 2 of them can be accessed by fs::Metadata
, they are is_dir()
and is_file()
(yes, same names!).
But, keep in mind that they are all mutually exclusive, that is, a file can never be of directory type and file type, or file type and symlink type.
Problems (I'm confused about this O.o)
Considering that we got the metadata from a file:
let metadata = fs::symlink_metadata("file").unwrap();
If we want to know if the file is a symbolic link, we have 2 ways:
- Without acessing
.file_type()
:
let is_symlink: bool = !(metadata.is_dir() || metadata.is_file()); // This is wrong, see conversation below
- Getting the
fs::FileType
:
metadata.is_symlink();
So, if the information is already accessible without file_type()
, why isn't a is_symlink()
function at fs::Metadata
just like is_dir()
and is_file()
?
Is some other reason that I'm not aware of?
Conclusion and proposals (need more discussion)
There's no point on having functions in fs::Metadata
that are exactly equal to what is available getting fs::FileType
by calling file_type()
.
I originally wanted to propose the removal of is_dir()
and is_file()
from fs::Metadata
, but maybe this would make getting the file_type a little too long, so here are my proposals to fix it sanely.
Ranked by the solutions I personally find the better for the language (please add comments into the debate):
- Deprecate
is_dir()
andis_file()
fromfs::Metadata
, and addfs::file_type
that returns directly thefs::FileType
. - Just deprecate
is_dir()
andis_file()
fromfs::Metadata
. - Add another redundant function,
fs::Metadata::is_symlink()
, to help likeis_file()
andis_dir()
have been doing since1.1.0
(we're at1.4.8
at the time of this writing).