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 was archived by the owner on Aug 16, 2021. It is now read-only.
First, nothing stops you from implementing Clone for a type that implements Fail. Errors in general can be Clone just like any other type, because unlike error-chain we don't inject a trait object into your error type.
However, the Error type provided by failure itself is not Clone, because it is essentially a trait object. It has occurred to me that we could make it into an Arc instead of a Box, but we can't do that backwards compatibly because we exposed the downcast_mut method on `Error. I don't feel great about this because I think mutating an error is an anti-pattern, whereas cloning it is not. But I don't know what to do.
If the issue is "we can't make breaking changes to Error &c. because then things using old-failure won't be using the same types as things using new-failure" ...I am probably completely ignorant of how this sort of thing actually works, and if so I will apologise and continue to watch and learn things — but could you instead of the dtolnay trick, do something like making new-failure import the type from old-failure and impl From<old-failure::Error> for Error?
I think coherence won't let us provide that impl. That would solve the most annoying problems but not all of them, e.g. if Error is a part of the signature of a trait method and its being implemented by another crate using the other Error type.
Currently grepping the source of all reverse dependencies to find out if anyone actually uses downcast_mut ever.
Actually, nevermind. This would also invalidate downcast (by value). I don't want to give up the ability to turn an Error into a concrete value again.
In theory, Clone will some day be object-safe using alloca. Unfortunately, we can't then add Clone as a supertrait on Fail without breaking everything. So I think Error will never be Clone.
Fortunately, there are several work arounds:
Rc<Error> and Arc<Error>.
Using your own type that implements Clone and Fail.
Activity
withoutboats commentedon Feb 3, 2018
First, nothing stops you from implementing
Clone
for a type that implementsFail
. Errors in general can beClone
just like any other type, because unlike error-chain we don't inject a trait object into your error type.However, the
Error
type provided by failure itself is notClone
, because it is essentially a trait object. It has occurred to me that we could make it into anArc
instead of aBox
, but we can't do that backwards compatibly because we exposed thedowncast_mut
method on `Error. I don't feel great about this because I think mutating an error is an anti-pattern, whereas cloning it is not. But I don't know what to do.Celti commentedon Feb 3, 2018
If the issue is "we can't make breaking changes to
Error
&c. because then things using old-failure won't be using the same types as things using new-failure" ...I am probably completely ignorant of how this sort of thing actually works, and if so I will apologise and continue to watch and learn things — but could you instead of the dtolnay trick, do something like making new-failure import the type from old-failure andimpl From<old-failure::Error> for Error
?withoutboats commentedon Feb 3, 2018
I think coherence won't let us provide that impl. That would solve the most annoying problems but not all of them, e.g. if
Error
is a part of the signature of a trait method and its being implemented by another crate using the otherError
type.Currently grepping the source of all reverse dependencies to find out if anyone actually uses
downcast_mut
ever.withoutboats commentedon Feb 3, 2018
Actually, nevermind. This would also invalidate
downcast
(by value). I don't want to give up the ability to turn anError
into a concrete value again.In theory,
Clone
will some day be object-safe using alloca. Unfortunately, we can't then addClone
as a supertrait onFail
without breaking everything. So I thinkError
will never beClone
.Fortunately, there are several work arounds:
Rc<Error>
andArc<Error>
.Clone
andFail
.c410-f3r commentedon Feb 4, 2018
Thanks @withoutboats for the great explanation! The
Arc
andRc
approach is a nice workaround for this problem.Stub out references to e.clone() until later.