API review: return types

[soc]

Currently the whole API assumes that home_dir cannot realistically fail (which is currently the case, because env::home_dir is broken and ignores errors).

If the implementation of home_dirs is changed to not ignore errors and starts returning Option<PathBuf> – what shall be done with all the other functions like config_dir() -> PathBuf or data_dir() -> PathBuf that rely on home_dir() as a (not to unlikely) fallback?

Turning them all into Options would be pretty bad, because these function can't fail on MacOS or Windows.

[soc]

Welp ... upon closer inspection I realized that most functions in dirs return Option already. :-/

So I guess there is pretty much no point in trying to retain the few PathBuf-returning functions over using Option<PathBuf> everywhere.

[soc]

It looks like the better question to ask is whether returning Option<PathBuf> is actually sufficient for functions that rely on home_dir, or if it is more reasonable to use Result to differentiate between errors caused by home_dir failing and errors caused by the function itself failing, e. g.: executable_dir could either fail because

• home_dir failed
• no executable dir exists on the platform

[Johannes Hofmann]

I think there is no downside to using Result as it can be easily converted to an Option. Maybe a lightweight enum without inner type would be sufficient as the Err variant?

[soc]

@b-r-u Thanks for the suggestion!

I also considered this, but went for Option (for no elaborate reason) ... I'm open to changing this, although this would mean incrementing the major version to 2.0, because I already shipped 1.0 yesterday. :-/

What do you think?

[Johannes Hofmann]

I'm not familiar with the different error conditions but if it's unlikely for users of the library to care about them then Option would be the best option :)