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
Nor will any other trick that isn't a straight up impl !Unpin.
Right now, if you use pin_project with a struct, you cannot impl !Unpin for that struct, which means that struct cannot implement Trait if it does not fall under the blanket impl. Would you accept a PR adding some way to impl !Unpin? For example, something like:
// creates an `impl !Unpin`, instead of an impl Unpin conditional on the impossible#[pin_project(!Unpin=negative_impls)]structStruct{ ... }
I'm not opposed to supporting unstable features under an explicit option.
However, negative_impls breaks pin_project's soundness (#340), so I prefer not to provide features that require negative_impls to be enabled until that problem is fixed.
Suppose I have the following trait definition:
And I use it from another crate. Then this will not have overlapping impls:
... because Rust understands that this doesn't overlap with the blanket impl in the trait definition. But this will not work:
Nor will any other trick that isn't a straight up
impl !Unpin
.Right now, if you use
pin_project
with a struct, you cannotimpl !Unpin
for that struct, which means that struct cannot implementTrait
if it does not fall under the blanket impl. Would you accept a PR adding some way toimpl !Unpin
? For example, something like:( In particular, I want this for https://github.com/google/crubit/blob/main/rs_bindings_from_cc/support/ctor.rs )
The text was updated successfully, but these errors were encountered: