Skip to content
This repository has been archived by the owner on Sep 13, 2023. It is now read-only.

Move Result type out of the prelude #66

Open
mistydemeo opened this issue Feb 19, 2018 · 2 comments
Open

Move Result type out of the prelude #66

mistydemeo opened this issue Feb 19, 2018 · 2 comments
Labels
good first issue Good for newcomers

Comments

@mistydemeo
Copy link

mistydemeo commented Feb 19, 2018

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.

@killercup killercup added the good first issue Good for newcomers label Feb 19, 2018
@killercup
Copy link
Owner

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)

@mistydemeo
Copy link
Author

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants