Skip to content
This repository has been archived by the owner on Aug 16, 2021. It is now read-only.

iter_causes is only implemented on trait objects #248

Open
fitzgen opened this issue Aug 24, 2018 · 3 comments
Open

iter_causes is only implemented on trait objects #248

fitzgen opened this issue Aug 24, 2018 · 3 comments

Comments

@fitzgen
Copy link

fitzgen commented Aug 24, 2018

This means that one has to either use UFCS or casting into a trait object to actually use the method:

let e: failure::Error = get_the_error_from_somewhere();

// Have to use UFCS (to implicitly create a trait object):
for c in Fail::iter_causes(&e) {
    // ...
}

// or explicitly turn the error into a trait object:
for c in (&e as &Fail).iter_causes() {
    // ...
}

// but I really just want to do this:
for c in e.iter_causes() {
    // ...
}

iter_causes should also be a provided method for all implementations of the trait:

trait Fail {
    // ...

    fn iter_causes(&self) -> Causes {
        // the default implementation here...
    }
}

Note that adding an iter_causes method to failure::Error is sufficient to fix the first example, and let it use iter_causes directly, but it won't fix the issue for any other type that implements failure::Fail.

@dekellum
Copy link

Ran into needing to use UFCS in example usage of #233 (and my #244). Thanks for the explanation! I hadn't figured out why that was necessary. In #244 I added a module helper function to work around it. Would it be appropriate to review the reasoning for all the impl Fail methods vs implementing the same in trait Fail? I've actually never seen this usage of impl <TraitSymbol> before!?!

@mitsuhiko
Copy link
Contributor

@fitzgen we removed that because it caused too many issues: #211

@Diggsey
Copy link

Diggsey commented Oct 7, 2018

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

No branches or pull requests

4 participants