Comments (5)
Hey, thank you for reporting this breakage. Our policy is to follow SemVer as defined by cargo1, definitely not to break existing code. We appreciate and want to encourage users who report unexpected breakages when they encounter them.
That said, it's my understanding that adding new items is not considered a major change in the rust ecosystem and our usage of semver23, even when it introduces breakage with globs.
We discussed this change in our team meeting today4 and considered the trade-offs of the proposed fix vs the current situation. One team member pointed out that the cargo team explicitly acknowledges glob imports as a forward compatibility hazard.
This is not considered a major change because conventionally glob imports are a known forwards-compatibility hazard. Glob imports of items from external crates should be avoided.
The main concern we discussed was API consistency; we already export other types with commonly used names such as Result
and Report
(aliased to Error
!). Our unanimous5 preference was to provide a name that is consistent with existing APIs rather than provide the fix and expect users to write use eyre::EyreOk as Ok;
. This also has the added benefit of not introducing yet another breaking change to update the name to fix the previous breakage with globs. I'm really sorry for the inconvenience this has caused, and thank you again for the issue and the PR; we really appreciate them.
Footnotes
-
https://doc.rust-lang.org/cargo/reference/semver.html#item-new ↩
-
https://predr.ag/blog/some-rust-breaking-changes-do-not-require-major-version/ ↩
-
of the subset of team members present ↩
from eyre.
I suggest not breaking existing code. Maybe rename Ok()
to EyreOk()
.
If I want to use eyre::*
, it's funny to import something like use std::result::Result::Ok
from eyre.
All that said, I wanna be clear that I do not intend to shut down the discussion around the second concern you raised about the ergonomics of the API.
Even worse, the following code in the same file can't be ergonomic with fn Ok.
That seems like something we should still try to improve if we can or at least provide guidance for how to work around the issue.
from eyre.
Hi, thank you for your prompt discussion.
I understand that the PR tires to reflect changes 3 years ago in anyhow dtolnay/anyhow#192 (comment)
However, the original issue was not discussed at all because it seemed trivial, considering wildcard being forward compatible hazard. I hope I had engaged in the issue back then.
While removing or renaming in anyhow is already too late, it's still time to do something in eyre.
I think the final goal of this function is to type less keystrokes, not to cause problems or fatigue the end user. Compare
use eyre::;
std::Result::Ok()
and
use eyre::{Ok as EyreOk}; // to be useful
EyreOk()
and just
use eyre::;
EyreOk()
And consider their frequency in code
from eyre.
If you have any other ergonomic improvements you'd like to suggest, please open a new issue! Compatibility breakages are expected from globbing as Jane mentioned. Renaming Eyre::Ok to Eyre::{Ok as EyreOk} is a valid way of importing.
When all else is equal, eyre prefers to maintain compatibility with anyhow. That's the main goal.
from eyre.
Related Issues (20)
- `eyre!(x)` where `x: Arc<eyre::Report>` loses trace HOT 1
- Integration with wasm-bindgen and conversion to `Result<T, JsValue>`
- Remove obsolete private_in_public lint in nightly. HOT 1
- Avoid filename collision in the monorepo structure
- Handle future-incompat dependencies HOT 2
- 0.6.9 fails to build on unstable-less nightly HOT 14
- Extend `Option` with `ok_or_eyre`? HOT 2
- Improve discoverability of `OptionExt::ok_or_eyre` HOT 2
- Ergonomics: Hide `context` behind a feature HOT 4
- [breaking] remove alias exports `DefaultContext` and `EyreContext`
- [breaking] Remove `anyhow` from default features HOT 2
- `cargo doc` warning: "this URL is not a hyperlink"
- Segfault in `Report::downcast()` introduced in 0.6.9 HOT 6
- enable raw mode compatibility for panic & error reports HOT 1
- `OptionExt` feature test is incorrectly feature-gated behind the `anyhow` flag
- [ BREAKING ] `ContextCompat` contains identically named methods to `WrapErr` which can be confusing and a footgun HOT 1
- [email protected] missing in the repository? HOT 2
- Eyre broken in rust-analyzer with nightly HOT 1
- and_then() that automatically converts error type to Report? HOT 11
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from eyre.