Is there a way to use a reference with a non-static lifetime in a custom Fail type? If so, I can't figure out the syntax to specify the lifetimes.
Currently, Fail requires the type is 'static, which means you can't have lifetimes in it. This is so that other code can assume that errors don't have lifetimes, but we might loosen the restriction if it seems like it was a mistake.
What is your use case where you want to have lifetimes?
I only have references for some of the things I want to include in the error. If there was a way to specify lifetimes, I wouldn't have to clone them.
The problem usually is that often the error gets returned up outside of the scope those lifetimes refer to, so ultimately you'd get lifetime errors when you try to return the error. If you're going to handle the error immediately, probably its fine if it just doesn't implement Fail or any error trait at all.
Unless you think the error's going to occur very frequently, cloning them is probably fine. If it is, you may need shared ownership.
But not always. In my case, I'm writing parsers where each error in the chain is a tagged enum consisting of production name + chunk of input it couldn't parse (from more specific ones to more generic one). In this case, I just want all of them to point to the original &str so that on consumer side I could either print one of them or calculate positions within a string etc. - something not possible with a cloned copy.
Of course, I could split each error into a tuple of production and chunk of input, but that would be rather inconvenient to use, especially given that this change would be required just to workaround limitations in the failure crate which, as you said, might be lifted later.
Is this in an application or a library? If the latter, what about when your users want to throw the error further up? If the former, what benefit do you see in implementing Fail for this error type?
1 Like