Skip to content
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

Relax Debug bounds on IpcReceiver and IpcSender #88

Open
nox opened this issue Jul 18, 2016 · 5 comments
Open

Relax Debug bounds on IpcReceiver and IpcSender #88

nox opened this issue Jul 18, 2016 · 5 comments
Assignees

Comments

@nox
Copy link
Contributor

nox commented Jul 18, 2016

Their Debug impls shouldn't require T: Debug.

@antrik
Copy link
Contributor

antrik commented Jul 18, 2016

I think the actual problem is that for some reason deriving Debug on something with PhantomData<T> requires T:Debug? Not sure why it does though -- doesn't make sense to me...

@nox
Copy link
Contributor Author

nox commented Jul 18, 2016

No that's only because we derive their implementation, we don't need the bound if we implement it ourselves.

@antrik
Copy link
Contributor

antrik commented Aug 20, 2016

@nox yes -- my point was that I don't see why the derived implementation has to impose these bounds, if a custom implementation doing exactly the same doesn't need it... Unless the derived implementation actually does something else that I'm missing? Otherwise I consider it a shortcoming in Rust, that should be fixed rather than working around it.

@nox
Copy link
Contributor Author

nox commented Aug 20, 2016

@antrik It's not really fixable easily in Rust, so we work around it here, nothing too surprising. It's hard for rustc to know which bounds to use for which types.

@nox
Copy link
Contributor Author

nox commented Aug 20, 2016

I think a recent nightly does it better, but that means that stable won't derive the same thing for now AFAIK.

@nox nox self-assigned this Mar 4, 2017
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

No branches or pull requests

2 participants