> Also if you think it would be wrong to allow one to attempt to open a file using any type that can be transformed to a C string, then you might want to think

> Also if you think it would be wrong to allow one to attempt to open a file using any type that can be transformed to a C string, then you might want to think about having a tiny wrapper trait with a more semantic name, like .to_path_str(), which would be generic over .to_c_str() and simply call that method on itself. Certainly, and for two reasons. First off, it's weakly typed. If, say, an integer type has a to_c_str() method, it does not mean that it should be possible to use it in File::open(). Secondly, the reliance of File::open() on to_c_str() is an implementation detail. At the end of the day, I can't say that having to write File::open(Path::new("foo.txt")) instead of File::open("foo.txt") is a huge burden. Actually, I'd even go the other way and distinguish between absolute (AbsPath) and relative (RelPath) versions of Path.