That seems like it would lead to people writing higher-level code constantly being unsure whether paths would get logged or not. Might actually be worse than not having it at all.
Well, I really am rejecting the "let the programmer decide" position out of hand, but I don't think that means there's no use discussing it. I mean, I'm the one asking for a change here, I have to persuade you that the programmer shouldn't be allowed to decide.
The trouble with "let the programmer decide" is that, and this is 20 years of bitter experience talking, every time a programmer thinks they don't need to report the offending file name(s) when a system call fails, they are wrong. D. Richard Hipp thought that users of SQLite didn't need to know whether a database open failed because the user didn't have read access to the main database file, or because they didn't have write access to the journal file. He was wrong. Any number of people writing Makefiles have thought it was OK to hide the full compiler command lines, because nobody needs to debug a build robot that they don't have direct access to, using only the log files, with a multi-day turnaround for modifications. They are wrong. At least two undergraduates every year think they don't need to print out the file name when
fopen fails, and I tell them otherwise, and they are dumbfounded to discover that the problem is obvious once they do that.
And because programmers have this tendency to think, incorrectly, that the filename isn't always a necessary piece of information, crate authors can't be trusted to capture it.
(Honestly, one of the things I don't like about "everyone makes up their own error type" is that I don't trust crate authors to chain in an underlying
io::Error every single time either. I want it to be a compile-time failure if you don't.)
This is true when you are only one or two levels up the call stack, but it is not true when you have crossed an abstraction boundary. Look again at the
DirBuilder::create_dir_all example I gave: when that fails, the application knows the path it passed in, but it doesn't know the path that actually provoked an error from the operating system, which could be any prefix of the input path.