RFC: Change cross platform API

[NilsIrl]

No description provided.

[ArturKovacs]

Don't mind the test failing, I'll fix those later.

Regarding the changes themselves. The reason why I put those functions into a module named linux_windows was to make it explicit that those functions are only avaiable on Windows and Linux. But let's say that users don't need to refer to that module to access the functions. Now if someone uses them while developing on one of those platforms, they might expect that those functions will just automatically work on a Mac too, because trash "supports" the Mac OS. But this way it's much clearer what is supported where. And still if the user of the crate doesn't want to type that long module name every time, they can import it with a different name like

use trash::linux_windows as trash_wl;

Or as you did in the PR simply just

use trash::linux_windows::*;

[NilsIrl]

The reason I prefer it this way, is that the API is less likely to break if a platform is added or if support for listing, purging... is added to MacOS.

We just have to document, that some functions only work on certain platforms (I think there's even a way to have cargo doc do it for us). And if someone compiles for a platform that doesn't support it they'll have a compile error.

[ArturKovacs]

I see. You have a point there. With that I think it mostly comes down to how likely it is that the functions in question will be implemented on Mac OS, and if they will be, when will that happen. For example the Rust standard library places functions which are available only on a specific platform, to a module with the name of that platform (see here)

I'm a bit pessimistic about that happening anytime soon if at all and to be honest I don't mind breaking the API this way because it's quite easy to refactor when all items of a module are moved to a different module. Is there a more significant consequence of such an API breaking chage that I can't think of right now?

[NilsIrl]

Is there a more significant consequence of such an API breaking chage that I can't think of right now?

not that I know of