You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 13, 2023. It is now read-only.
The Result type exposed by quicli::prelude conflicts with the Result type that's in the default Rust namespace, since it has a different type signature. This makes it inconvenient to drop quicli into existing projects. It'd be great to move this out of the prelude and make it an optional import instead.
For example, here's a PR where I'm switching from bare clap to quicli. I ended up tossing a use std::result::Result right after the quicli prelude import, which is the kind of thing which makes me think this should work the other way around.
The text was updated successfully, but these errors were encountered:
Yeah, I regret adding it to the prelude in retrospect. In addition to your case with existing code, error handling is one of the less obvious things to many people coming to Rust from other languages, so this is also needlessly confusing them further.
I imagine fix here that is two-fold. First:
Change the name of the type alias to QuickResult (or something like that, feel free to bikeshed)
Document this type alias thoroughly
And then:
Write a guide that covers error handling in more detail (and that also links to failure's docs)
Change the name of the type alias to QuickResult (or something like that, feel free to bikeshed)
I'd also really like to see it moved out of the prelude and made into an optional import. Compared to the other items in the prelude, it's much more tenuously connected to this crate's main features.
The
Result
type exposed byquicli::prelude
conflicts with theResult
type that's in the default Rust namespace, since it has a different type signature. This makes it inconvenient to drop quicli into existing projects. It'd be great to move this out of the prelude and make it an optional import instead.For example, here's a PR where I'm switching from bare clap to quicli. I ended up tossing a
use std::result::Result
right after the quicli prelude import, which is the kind of thing which makes me think this should work the other way around.The text was updated successfully, but these errors were encountered: