ok; and do we implement
(in other words, it's probably not important where
.await autoderefs at this point...)
await does not autoderef
Yes, we implement
Future for boxed future types
awaitdoes not autoderef
I am aware
but I feel like we might want it to in the future, if we had deref-move
( just for consistency with
I'm quite skeptical
but I mostly want to not care about this right now :)
I don't think the motivation for this is strong.
I don't know how much it'll ever matter in practice
it's just a "consistency thing"
I've never heard anyone mention it, and in many cases the autoderef woudn't "do the right thing"
&mut F and
Pin<&mut F> and
Pin<Box<F>> always implement
(/me mutters about how annoying it is that people said we shouldn't be able to pin-project through
@Taylor Cramer my only question is: are we forward compatible with auto-deref?
I think you hinted at yes, but would be good to confirm more explicitly
@centril from what I can tell the answer is yes --
basically, we would only auto-deref in cases that would be an error today anyway
(I was trying to think of edge cases but it feels like any such edge-case would be a bug in the auto-deref algorithm anyway)
i.e., the concern would be cases where we don't know enough type info to decide yet
but we're supposed to be conservative in such cases
the problem would be
if we added DerefMove without thinking about it..
..well, that's not true either I guess
@nikomatsakis I guess the one thing I thought of was if we had some impl for
Future that would create problems later
I'm not sure I follow
@nikomatsakis it's quite an unbaked thought, but could it be the case that we have a blanket-ish impl for
Future that cannot be subsumed by auto-deref and which wouldn't be selected if we later added auto-deref?
I can't think how -- usually the idea is that we only add a deref if there is no other possibility
ah; in that case, then it should be all good