-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fs::Metadata::is_dir() and is_file() should be deprecated #76487
Comments
Some of this inconsistency seems to be ""explained"" by the order things got added. Both functions were already present in
|
Without going deeply into the issue: stable functions cannot be removed from std. |
I disagree that they should be deprecated. They provide a convenient shorthand for what would otherwise require an additional function call and are widely used in the ecosystem. Deprecating them would produce widespread warnings for no good reason. |
Opened files are not symlinks because the OS will resolve the symlink before opening (barring cases such as
This is not correct since there can be file types other than symlinks or directories. See https://doc.rust-lang.org/std/os/unix/fs/trait.FileTypeExt.html |
Correct, but this isn't related to the issue I explained above, I had to explicitly check for file types in a current project and I found out that there is no
You're right, maybe I should take the opportunity to make an PR to make this clearer in the documentation.
Thanks for this information, indeed, |
I understand your point, but if this is intended to provide a convenient shorthand, then where is the This makes code weirder. let is_file = path.symlink_metadata()?.is_file();
let is_dir = path.symlink_metadata()?.is_dir();
let is_symlink = path.symlink_metadata()?.file_type().is_symlink(); |
You can always write let is_file = path.symlink_metadata()?.file_type().is_file();
let is_dir = path.symlink_metadata()?.file_type().is_dir();
let is_symlink = path.symlink_metadata()?.file_type().is_symlink(); Nothing says you must use the metadata functions.
Sure, I guess referring to |
I see now that suggesting deprecation (and removal) of heavily used functions was reckless by me. However, I still think that we should add the short hand In this case, |
Closing because |
Resume
I'm personally confused about the existence of
fs::Metadata::is_dir()
andfs::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 afs::FileType
fs::FileType
just contains 3 functions, 2 of them can be accessed byfs::Metadata
, they areis_dir()
andis_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:
If we want to know if the file is a symbolic link, we have 2 ways:
.file_type()
:fs::FileType
:So, if the information is already accessible without
file_type()
, why isn't ais_symlink()
function atfs::Metadata
just likeis_dir()
andis_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 gettingfs::FileType
by callingfile_type()
.I originally wanted to propose the removal of
is_dir()
andis_file()
fromfs::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):
is_dir()
andis_file()
fromfs::Metadata
, and addfs::file_type
that returns directly thefs::FileType
.is_dir()
andis_file()
fromfs::Metadata
.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).The text was updated successfully, but these errors were encountered: