Closed
Description
Looking at https://doc.rust-lang.org/nightly/std/pin/struct.Pin.html, I see that Pin::set takes self
by value. This is unlike the API that was proposed in the tracking issue #55766, which would take &mut self
instead, and I could not find a rationale for this discrepancy in the tracking issue.
Is this intended? If not, you may want to fix this before the Pin stabilization actually hits beta/stable 😉
Activity
cramertj commentedon Jan 4, 2019
This is what I implemented and what I intended when I implemented it, but I didn't notice the discrepancy with @withoutboats's stabilization report. If they feel that this should be changed, it seems worth discussing, otherwise I'm comfortable moving forward with it as-is. The choice here is whether or not to build-in reborrowing into the method or to require a call to
.as_mut()
to reborrow thePin
.HadrienG2 commentedon Jan 4, 2019
Just to make sure I understand the implications, does the following code behave as I expect?
And if so, what is the intended use case for
Pin::set()
?HadrienG2 commentedon Jan 4, 2019
Oh, wait, I think I understand your earlier remark about
as_mut()
. Since&mut T
implementsDerefMut<Target=T>
, this should work:Coming from a world of pointers and references, it decidedly feels odd to need to manually reborrow like this in order to avoid losing access to the
&mut
by merely writing into it. But maybe I misunderstood something.cramertj commentedon Jan 4, 2019
It does feel odd to need to manually reborrow, and its unfortunate that
Pin<&mut T>
requires this, unlike&mut T
which does it automatically. However, I hope this restriction will be lifted in the future.HadrienG2 commentedon Jan 5, 2019
I see, if the plan is to enable reborrow semantics later on it does make more sense !
withoutboats commentedon Jan 5, 2019
Is there a reason you would not want reborrow semantics? The current API is technically the most "broad," but if what it enables is useless (I can't think of a use), we could just backport a change to the API.
withoutboats commentedon Jan 5, 2019
(The discrepancy with the stabilization report was a mistake on my part I believe; I don't remember noting this and I didn't list it as a change to be made before stabilizing)
HadrienG2 commentedon Jan 5, 2019
Sorry, I worded my last comment very poorly. What I meant is, if the plan is to eventually give
Pin<&mut T>
special semantics as a self type, so thatself: Pin<&mut T>
does not consume the Pin (like&mut self
does not consume the reference), then I understand the design of this API better.withoutboats commentedon Jan 5, 2019
I was responding to the issue, not your last comment. I think it would be strictly better to make this change while we still can.
cramertj commentedon Jan 7, 2019
@withoutboats I don't have any strong feelings either way. I'll open a PR to change and we can see if anyone opposes or otherwise merge it.
Pin::set
#57419Auto merge of #57419 - cramertj:pin-set, r=withouboats