Stream: wg-async-foundations

Topic: `x.await` move


nikomatsakis (May 13 2019 at 19:40, on Zulip):

So does x.await move x?

Taylor Cramer (May 13 2019 at 19:58, on Zulip):

Yes.

nikomatsakis (May 13 2019 at 19:58, on Zulip):

ok; and do we implement Future for Box<impl Future>?

nikomatsakis (May 13 2019 at 19:59, on Zulip):

(in other words, it's probably not important where .await autoderefs at this point...)

Taylor Cramer (May 13 2019 at 19:59, on Zulip):

await does not autoderef

Taylor Cramer (May 13 2019 at 19:59, on Zulip):

Yes, we implement Future for boxed future types

nikomatsakis (May 13 2019 at 20:00, on Zulip):

await does not autoderef

I am aware

nikomatsakis (May 13 2019 at 20:00, on Zulip):

but I feel like we might want it to in the future, if we had deref-move

nikomatsakis (May 13 2019 at 20:00, on Zulip):

( just for consistency with .field, .method() )

Taylor Cramer (May 13 2019 at 20:00, on Zulip):

I'm quite skeptical

nikomatsakis (May 13 2019 at 20:00, on Zulip):

but I mostly want to not care about this right now :)

Taylor Cramer (May 13 2019 at 20:00, on Zulip):

yeah

Taylor Cramer (May 13 2019 at 20:01, on Zulip):

I don't think the motivation for this is strong.

nikomatsakis (May 13 2019 at 20:01, on Zulip):

I agree

nikomatsakis (May 13 2019 at 20:01, on Zulip):

I don't know how much it'll ever matter in practice

nikomatsakis (May 13 2019 at 20:01, on Zulip):

it's just a "consistency thing"

Taylor Cramer (May 13 2019 at 20:01, on Zulip):

I've never heard anyone mention it, and in many cases the autoderef woudn't "do the right thing"

Taylor Cramer (May 13 2019 at 20:02, on Zulip):

like, &mut F and Box<F> implement Future when F: Unpin

Taylor Cramer (May 13 2019 at 20:02, on Zulip):

and Pin<&mut F> and Pin<Box<F>> always implement Future

Taylor Cramer (May 13 2019 at 20:02, on Zulip):

(/me mutters about how annoying it is that people said we shouldn't be able to pin-project through Box)

Taylor Cramer (May 13 2019 at 20:03, on Zulip):

but w/e

centril (May 13 2019 at 20:15, on Zulip):

@Taylor Cramer my only question is: are we forward compatible with auto-deref?

centril (May 13 2019 at 20:16, on Zulip):

I think you hinted at yes, but would be good to confirm more explicitly

nikomatsakis (May 13 2019 at 20:36, on Zulip):

@centril from what I can tell the answer is yes --

nikomatsakis (May 13 2019 at 20:36, on Zulip):

basically, we would only auto-deref in cases that would be an error today anyway

nikomatsakis (May 13 2019 at 20:36, on Zulip):

(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)

nikomatsakis (May 13 2019 at 20:37, on Zulip):

i.e., the concern would be cases where we don't know enough type info to decide yet

nikomatsakis (May 13 2019 at 20:37, on Zulip):

but we're supposed to be conservative in such cases

centril (May 13 2019 at 20:37, on Zulip):

sgtm then

nikomatsakis (May 13 2019 at 20:37, on Zulip):

the problem would be

nikomatsakis (May 13 2019 at 20:37, on Zulip):

if we added DerefMove without thinking about it..

nikomatsakis (May 13 2019 at 20:37, on Zulip):

..well, that's not true either I guess

centril (May 13 2019 at 20:41, on Zulip):

@nikomatsakis I guess the one thing I thought of was if we had some impl for Future that would create problems later

nikomatsakis (May 13 2019 at 20:44, on Zulip):

I'm not sure I follow

centril (May 13 2019 at 20:49, on Zulip):

@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?

nikomatsakis (May 13 2019 at 20:50, on Zulip):

I can't think how -- usually the idea is that we only add a deref if there is no other possibility

centril (May 13 2019 at 20:53, on Zulip):

ah; in that case, then it should be all good

Last update: Nov 18 2019 at 01:20UTC