Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Pin stabilization #56939
Pin stabilization #56939
Changes from all commits
20d694a
610bcaf
3005bf3
684fe9a
861df06
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I talked with @withoutboats in person about this a bit as I was slightly concerned about this, so I just wanted to make sure to write down some thoughts. The
AsRef
trait is the libs team's worst offender in terms of "thorns in our side about backwards compatibility", as addingAsRef
anywhere seems to break due to subtle inference changes.Along those lines, I think it definitely makes sense to be consistent with
self
vs not inPin
, but I just wanted to raise this and make sure it'd been considered. I think @withoutboats mentioned they'd talk with you @cramertj about the ergonomic importance ofself
-vs-not. It seems like the primary motivation forself
everywhere was ergonomics, and I'd just want to make sure it's well motivated to take such a common name likeas_ref
!Concretely my worry is that we may not be able to add inherent
self
-based methods toPin
in the future if they cause too much breakage in the ecosystem (due to shadowing conflicts), which would cause us to have two idioms.Again though, just wanted to make sure I brought that up and ensure it was weighed!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ergonomic improvement from
self
inas_mut
andset
at least are pretty important because it's common to see them chained, which gets pretty ugly otherwise. The most common instance of this isPin::get_mut_unchecked(Pin::as_mut(self))
inside futures-rs (it's pretty common to seePin::as_mut
used for reborrowing in combination with other methods).set
is another one where I personally just get it wrong every time and try to spell itself.set(value)
rather thanPin::set(Pin::as_mut(self), value);
-- I think you can probably see why ;).I'm totally sympathetic to the concerns here and am interested in any ideas you might have for making this easier. One thing I will say is that I think it's much more common to call
Pin
methods on aPin<P<T>>
than it is to call e.g.Rc
methods on anRc<T>
, so I'd been using that to justify to myself whyPin
was "different" in this respect.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok sure thing, I just wanted to double-confirm. I agree that the usage pattern of
Pin
seems like it favors inherent methods more often is good motivation for breaking the norm.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing @alexcrichton and I talked about was making only as_ref and as_mut associated functions, so you'd get
Pin::as_mut(self).get_mut_unchecked
and so on. What would you think about that @cramertj?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd probably want something not called
as_mut
that did reborrowing in that case. I can define it as a trait in thepin_utils
crate or something, but that seems like it kind of defeats the purpose.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(to be clear: I'm fine making this change if it's the one @rust-lang/libs wants, it's just much more ergonomic and easier to read the chained-method version)