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

[DO NOT MERGE] Allow a type implementing phy::Device to contain borrowed data #697

Closed
wants to merge 2 commits into from

Conversation

ebarnard
Copy link
Contributor

Previously, a limitation of Rust's type system required a device to
implement phy::Device<'a> for all lifetimes, including 'static, to
be able to call methods on iface::Interface. This prevented types
implementing phy::Device<'a> from containing any borrowed data.

Now that Rust supports GATs (generic associated types), it is possible
to lift this restriction and allow implementations of phy::Device<'a>
which contain borrowed data.

@ebarnard ebarnard changed the title Allow a type implementing phy::Device to contain borrowed data [DO NOT MERGE] Allow a type implementing phy::Device to contain borrowed data Oct 22, 2022
@ebarnard
Copy link
Contributor Author

This is not yet ready to merge. It requires GATs in stable which is set to be released in Rust 1.65 on 3rd Nov.

@ebarnard ebarnard force-pushed the device-gats branch 2 times, most recently from bb0b614 to 8da5806 Compare October 22, 2022 14:50
@thvdveld thvdveld marked this pull request as draft October 22, 2022 14:54
Previously, a limitation of Rust's type system required a device to
implement `phy::Device<'a>` for all lifetimes, including `'static`, to
be able to call methods on `iface::Interface`. This prevented types
implementing `phy::Device<'a>` from containing any borrowed data.

Now that Rust supports GATs (generic associated types), it is possible
to lift this restriction and allow implementations of `phy::Device<'a>`
which contain borrowed data.
@adamgreig
Copy link
Contributor

I haven't checked the code diffs, but this sounds similar to #572 ?

@ebarnard
Copy link
Contributor Author

It's exactly the same. I even looked at the list of open PRs before starting this. Oh well.

Closing in favour of the existing #572.

@ebarnard ebarnard closed this Oct 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants