-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A couple of improvements #22
Conversation
27b5ab5
to
856eae1
Compare
Thanks for these improvements! My only concern is about the |
I will drop the |
856eae1
to
5848559
Compare
I'm improving this crate for a new major release, so I don't mind breaking the API now (especially this small), but it seems reasonable to be compatible with at least the latest Rust edition. I tested this commit and it passes all the tests without changing the Rust edition, so I guess it's not an issue (as long as rustc >= 1.63, which should be fine) and it will still be compatible with the Rust 2018 and 2021 editions, right? |
Anyway, the |
Nothing in this PR should cause any MSRV increase.
I mean that if I use an AsFd bound when rustc >=1.63 is detected and AsRawFd otherwise, then the API will break between those cases, so you can have code which works on rustc 1.62, but breaks on rustc 1.63 due to rust-landlock automatically switching from AsRawFd to AsFd.
In rust editions allow breaking syntactic changes to be made in a way that allows older code to keep working on newer rustc versions by staying on an older edition. Anything that can be enabled on older editions will be enabled on them. So if a new api in libstd is introduced in a future rustc version, all editions will be allowed to use it when compiling with this future rustc version. As such there is no point in staying on a rust edition older than the latest edition supported by the oldest rustc version you want to use. For example if you want to support rustc 1.56 you will have to stay on the 2018 edition, but if you only support rustc 1.57 (which introduced the 2021 edition) then you can use the 2021 edition without having any effect on users of your crate (as editions are invisible outside of the crate itself) or users who want to compile a project that uses your crate (as you already only support rustc 1.57 in this example) |
By the way what is actually the oldest rustc version you want to keep supporting? If you haven't decided yet, here are some suggestions:
|
Thanks for these explanations. OK, so the Rust edition doesn't imply to stick with a specific Rust version except for related syntax breaking changes, which is not the case to support Please create a new PR with the |
Opened #25. |
This allows using anyhow::Error as error type even though it doesn't implement std::error::Error. Signed-off-by: Björn Roy Baron <[email protected]>
PathEnvError is not matched on, so it has no benefit over only using anyhow. Signed-off-by: Björn Roy Baron <[email protected]>
These haven't been necessary since the 2018 edition Signed-off-by: Björn Roy Baron <[email protected]>
5848559
to
5aa8d33
Compare
See the individual commits for why each change is an improvement in my opinion.