This is more akin to how APIs typically work in the rust std. The overhead is probably insignificant, and makes the Options API significantly easier to use, and lets your end-users pass in anything thats convertible to e.g. a Path (via reference) or a PathBuf (as an owned value).
Personally, regarding the Options struct over here, it'd be simpler to just store owned values (and so use PathBuf), e.g. instead of:
But, if you really wanna use Path objects and avoid copying, I'd use Cow<Path> pointers internally and then give the user the option of passing in owned values or references VIA e.g. P: AsRef<Path> or P: Into<PathBuf> (for passing in owned values specifically or just P: AsRef<Path> and clone it).
This api is kinda frustrating and the lifetimes are unnecessary, it should something akin to
This is more akin to how APIs typically work in the rust std. The overhead is probably insignificant, and makes the
Options
API significantly easier to use, and lets your end-users pass in anything thats convertible to e.g. aPath
(via reference) or aPathBuf
(as an owned value).Personally, regarding the
Options
struct over here, it'd be simpler to just store owned values (and so usePathBuf
), e.g. instead of:It should be
And just copy the values pass in VIA
But, if you really wanna use
Path
objects and avoid copying, I'd useCow<Path>
pointers internally and then give the user the option of passing in owned values or references VIA e.g.P: AsRef<Path>
orP: Into<PathBuf>
(for passing in owned values specifically or justP: AsRef<Path>
and clone it).