Skip to content

Drop the Sized constraint on impl Error for Box<T> #39792

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from

Conversation

sgrif
Copy link
Contributor

@sgrif sgrif commented Feb 13, 2017

Because of the implicit Sized constraint, Box<Error> does not
implement Error, which is potentially surprising when trying to pass
to a type which requires T: Error.

Because of the implicit `Sized` constraint, `Box<Error>` does not
implement `Error`, which is potentially surprising when trying to pass
to a type which requires `T: Error`.
@rust-highfive
Copy link
Contributor

r? @BurntSushi

(rust_highfive has picked a reviewer for you, use r? to override)

sgrif added a commit to diesel-rs/diesel that referenced this pull request Feb 13, 2017
This was always a fairly clunky API. Its main upside was that type
inference was able to figure out the error type in more cases than the
current implementation does. It has much larger downsides though. The
most common case is that you're just returning `diesel::result::Error`
anyway, so this enum was just an annoyance. If you weren't returning
that, you were probably returning an application specific error which
has a variant for `diesel::result::Error`, and now also had to handle
this additional type. It also turns out that
[`TransactionError<Box<::std::error::Error>>` doesn't implement
`::std::error::Error`](rust-lang/rust#39792).

The new API might require explicitly stating the error type in a few
more places (in particular `try!(conn.transaction(|| try!(query);
Ok(()))); Ok(...)` stopped inferring), but I think that this will end up
being more ergonomic for most uses.
sgrif added a commit to diesel-rs/diesel that referenced this pull request Feb 13, 2017
This was always a fairly clunky API. Its main upside was that type
inference was able to figure out the error type in more cases than the
current implementation does. It has much larger downsides though. The
most common case is that you're just returning `diesel::result::Error`
anyway, so this enum was just an annoyance. If you weren't returning
that, you were probably returning an application specific error which
has a variant for `diesel::result::Error`, and now also had to handle
this additional type. It also turns out that
[`TransactionError<Box<::std::error::Error>>` doesn't implement
`::std::error::Error`](rust-lang/rust#39792).

The new API might require explicitly stating the error type in a few
more places (in particular `try!(conn.transaction(|| try!(query);
Ok(()))); Ok(...)` stopped inferring), but I think that this will end up
being more ergonomic for most uses.
sgrif added a commit to diesel-rs/diesel that referenced this pull request Feb 13, 2017
This was always a fairly clunky API. Its main upside was that type
inference was able to figure out the error type in more cases than the
current implementation does. It has much larger downsides though. The
most common case is that you're just returning `diesel::result::Error`
anyway, so this enum was just an annoyance. If you weren't returning
that, you were probably returning an application specific error which
has a variant for `diesel::result::Error`, and now also had to handle
this additional type. It also turns out that
[`TransactionError<Box<::std::error::Error>>` doesn't implement
`::std::error::Error`](rust-lang/rust#39792).

The new API might require explicitly stating the error type in a few
more places (in particular `try!(conn.transaction(|| try!(query);
Ok(()))); Ok(...)` stopped inferring), but I think that this will end up
being more ergonomic for most uses.
@alexcrichton
Copy link
Member

I believe the coherence error is why we can't do this :(

@sgrif
Copy link
Contributor Author

sgrif commented Feb 13, 2017

Error + Send + Sync + 'a is a strict subset of Error + 'a, right? Can we fix this by rubbing some specialization on the more general one?

@alexcrichton
Copy link
Member

Wanna try it out? :)

I vaguely remember this being a rabbit hole, but if travis is green and we can add this, then seems good to me.

@sgrif
Copy link
Contributor Author

sgrif commented Feb 13, 2017

Hm. It didn't help. I don't see an obvious reason why (maybe something to do with Box being #[fundamental]?). Oh well.

@sgrif sgrif closed this Feb 13, 2017
sgrif added a commit to diesel-rs/diesel that referenced this pull request Feb 13, 2017
This was always a fairly clunky API. Its main upside was that type
inference was able to figure out the error type in more cases than the
current implementation does. It has much larger downsides though. The
most common case is that you're just returning `diesel::result::Error`
anyway, so this enum was just an annoyance. If you weren't returning
that, you were probably returning an application specific error which
has a variant for `diesel::result::Error`, and now also had to handle
this additional type. It also turns out that
[`TransactionError<Box<::std::error::Error>>` doesn't implement
`::std::error::Error`](rust-lang/rust#39792).

The new API might require explicitly stating the error type in a few
more places (in particular `try!(conn.transaction(|| try!(query);
Ok(()))); Ok(...)` stopped inferring), but I think that this will end up
being more ergonomic for most uses.
sgrif added a commit to diesel-rs/diesel that referenced this pull request Feb 14, 2017
This was always a fairly clunky API. Its main upside was that type
inference was able to figure out the error type in more cases than the
current implementation does. It has much larger downsides though. The
most common case is that you're just returning `diesel::result::Error`
anyway, so this enum was just an annoyance. If you weren't returning
that, you were probably returning an application specific error which
has a variant for `diesel::result::Error`, and now also had to handle
this additional type. It also turns out that
[`TransactionError<Box<::std::error::Error>>` doesn't implement
`::std::error::Error`](rust-lang/rust#39792).

The new API might require explicitly stating the error type in a few
more places (in particular `try!(conn.transaction(|| try!(query);
Ok(()))); Ok(...)` stopped inferring), but I think that this will end up
being more ergonomic for most uses.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants