Drop use of unstable try_trait_v2 feature#479
Conversation
|
Just an idea: would it be possible/a good idea to keep the current implementation around, but behind a feature flag, or is the only right solution to completely remove this code? |
c265404 to
466e19d
Compare
|
I've uploaded a variation that puts it behind an optional feature: #481 I don't have a strong opinion as to whether it's better to do it that way. It has the advantage of avoiding any potential downstream breakage as long as we have the feature enabled by default, but on the other hand it adds some small amount of complexity for an (IMO) small gain. So, I could really see it either way and would be happy with either option :) |
There are currently already breaking changes in the next release if I'm not mistaken (some removed functionality). I'd suggest to not create future technical debt here. What do you think? |
466e19d to
70e0d71
Compare
It seems like there's still a fair amount of discussion around what the Try API should look like in the tracking issue for try_trait_v2. This could lead to the API being changed in the nightly compiler, and breaking uefi-rs compilation (which is particularly annoying when using a released version rather than the latest git version). To avoid that possibility, just drop the feature as it is not much used in uefi-rs and can easily be replaced. As described in the changelog, most uses can be fixed by adding a call to `into()`. If the compiler needs a bit more help, `Result::from(status)` can be used. rust-osdev#452
70e0d71 to
fbfe833
Compare
|
Thanks both for reviewing. Never any harm in exploring a couple different alternatives, and I like where we ended up :) |
It seems like there's still a fair amount of discussion around what the
Try API should look like in the tracking issue for try_trait_v2. This
could lead to the API being changed in the nightly compiler, and
breaking uefi-rs compilation (which is particularly annoying when using
a released version rather than the latest git version).
To avoid that possibility, just drop the feature as it is not much used
in uefi-rs and can easily be replaced. As described in the changelog,
most uses can be fixed by adding a call to
into(). If the compilerneeds a bit more help,
Result::from(status)can be used.#452