Potential module refactors

[FenrirWolf]

The HID module isn't the only one that's in need of some love.

For example, I believe the current console API is technically unsound, since there are no guards on the values you can pass to set_window and I can't image good things happening when you exceed their proper limits. Not that resizing the console is an often used operation in the first place, but we still like safe APIs. I figure that changing console construction to a builder pattern (with convenience functions for default and full-screen consoles) and having the finished console window be structurally immutable would fix that.

I'm also thinking of changing the Error type from an enum to a struct, since I don't imagine that Error will ever be anything more than a newtype'd i32, and structs are more commonly used than enums for that pattern. Feel free to check me on that one though.

Are there any others modules that should be given a second pass? And how aggressive should we be with breaking existing code? My opinion is that we might as well be fairly aggressive, given that everything about this is already unstable to begin with and it's not like there's a huge install base either.

[HybridEidolon]

I'm all for switching the enums to structs if the convention for FFI wrappers is to use them for bitsets and such. I don't have a lot of stock in the API being any particular way, so long as it exposes a safe and usable interface.

[FenrirWolf]

Cool, that's good to know.

Also, I was wondering if I could have push permissions on the template repo. If we're gonna be breaking the API a lot it would be good to keep things up to date over there.

[FenrirWolf]

Another neat thing would be to implement a true mounting system for the fs stuff in ctru-rs, so that instead of having to pass around a token representing opened archives in the API, you could access them via Path prefixes instead, i.e. sdmc:/, save_file:/, ctrnand:/, raw_nand:/, or something similar