Stream: wg-async-foundations

Topic: weekly meeting 2019.04.09


Taylor Cramer (Apr 09 2019 at 17:00, on Zulip):

@WG-async-await o/

Taylor Cramer (Apr 09 2019 at 17:02, on Zulip):

remaining blockers: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AAsyncAwait-Blocking

Taylor Cramer (Apr 09 2019 at 17:03, on Zulip):

@nikomatsakis I think https://github.com/rust-lang/rust/issues/58930 is just waiting on you to review https://github.com/rust-lang/rust/pull/59111

Taylor Cramer (Apr 09 2019 at 17:03, on Zulip):

(cc @Giles Cope )

Taylor Cramer (Apr 09 2019 at 17:04, on Zulip):

@nikomatsakis and I were going to try and meet some time this week to discuss https://github.com/rust-lang/rust/issues/56238 (multiple lifetimes)

Taylor Cramer (Apr 09 2019 at 17:04, on Zulip):

We haven't yet scheduled a time, but when we do I'll make sure it gets announced on the stream.

Taylor Cramer (Apr 09 2019 at 17:05, on Zulip):

I think the plan was to record it as well so we'll have a record

Taylor Cramer (Apr 09 2019 at 17:05, on Zulip):

That work would also unblock some features of existential types

Taylor Cramer (Apr 09 2019 at 17:06, on Zulip):

On https://github.com/rust-lang/rust/issues/54716 (arguments are dropped early)

Taylor Cramer (Apr 09 2019 at 17:06, on Zulip):

there's been some lang team discussion at the last meeting and on the thread around whether or not we want to consider this a bug, and whether or not we should leave the current behavior

Taylor Cramer (Apr 09 2019 at 17:07, on Zulip):

still, I think we should take an optimistic-concurrency route and continue working towards a compiler-team solution

davidtwco (Apr 09 2019 at 17:07, on Zulip):

still, I think we should take an optimistic-concurrency route and continue working towards a compiler-team solution

I'm not familiar with what you mean by an optimistic-concurrency route?

Taylor Cramer (Apr 09 2019 at 17:07, on Zulip):

@davidtwco you had opened https://github.com/rust-lang/rust/pull/59135 which included a fix, but I know you were concerned that the implementation was a bit wonky

Taylor Cramer (Apr 09 2019 at 17:08, on Zulip):

@davidtwco ah, sorry, I was just referring to "work towards a solution on our end while the lang team also works towards a solution on theirs"

Taylor Cramer (Apr 09 2019 at 17:09, on Zulip):

@davidtwco did you have unresolved questions around how the implementation should work? is there something that needs to happen to unblock further work here?

davidtwco (Apr 09 2019 at 17:09, on Zulip):

davidtwco you had opened https://github.com/rust-lang/rust/pull/59135 which included a fix, but I know you were concerned that the implementation was a bit wonky

It was 95% of the way there, but it wasn't as clean as I'd have liked as the change leaked into the AST a little to simplify the changes to the HIR, name resolution and (def) collection.

davidtwco (Apr 09 2019 at 17:09, on Zulip):

There was an unresolved bug with type inference of the let <pat> = __arg0 statement.

davidtwco (Apr 09 2019 at 17:10, on Zulip):

And when that was fixed temporarily there was a change in some test output that looked fine but I wasn't too sure.

nikomatsakis (Apr 09 2019 at 17:10, on Zulip):

(Hi all, sorry I'm late)

nikomatsakis (Apr 09 2019 at 17:10, on Zulip):

nikomatsakis I think https://github.com/rust-lang/rust/issues/58930 is just waiting on you to review https://github.com/rust-lang/rust/pull/59111

ok

nikomatsakis (Apr 09 2019 at 17:11, on Zulip):

nikomatsakis and I were going to try and meet some time this week to discuss https://github.com/rust-lang/rust/issues/56238 (multiple lifetimes)

I was meaning to get back to you on that. I think we should schedule a time a bit later in the week (maybe Friday?) and I'll try to also add some time for me to do a bit of exploratory work before that. But I'll ping you in the other thread.

nikomatsakis (Apr 09 2019 at 17:12, on Zulip):

there's been some lang team discussion at the last meeting and on the thread around whether or not we want to consider this a bug, and whether or not we should leave the current behavior

I still think this should be considered a bug -- however I was thinking

nikomatsakis (Apr 09 2019 at 17:12, on Zulip):

in the short term, one very simple thing we could do is just limit async fns to only have simple patterns for their parameters, or something like that?

nikomatsakis (Apr 09 2019 at 17:12, on Zulip):

maybe that's too horrible

nikomatsakis (Apr 09 2019 at 17:12, on Zulip):

(also require, I guess, that all parameters are used)

nikomatsakis (Apr 09 2019 at 17:13, on Zulip):

obviously not a good long term sol'n, and maybe not worth the effort

davidtwco (Apr 09 2019 at 17:13, on Zulip):

It was 95% of the way there, but it wasn't as clean as I'd have liked as the change leaked into the AST a little to simplify the changes to the HIR, name resolution and (def) collection.

Elaborating slightly, inserting statements during lowering wasn't particularly easy and required similar changes to other parts of the compiler, which meant that constructing those statements in the AST so they were available in these other places proved easier.

davidtwco (Apr 09 2019 at 17:14, on Zulip):

obviously not a good long term sol'n, and maybe not worth the effort

Unless we don't want an approach as yucky as my previous PR took, I don't think it would be too hard to polish that up and fix the issue. (I'd need some help w/ the type inference issue, but otherwise the bulk is done).

nikomatsakis (Apr 09 2019 at 17:16, on Zulip):

It wasn't really clear to me how yucky that was

nikomatsakis (Apr 09 2019 at 17:16, on Zulip):

I get that it felt more complex than you would like though

nikomatsakis (Apr 09 2019 at 17:16, on Zulip):

(I didn't really read it that closely)

nikomatsakis (Apr 09 2019 at 17:17, on Zulip):

I guess I would say that I am inclined to say I'd rather land the PR you were working on, presuming we can close up the remaining holes

nikomatsakis (Apr 09 2019 at 17:17, on Zulip):

and then refactor to make it nicer

nikomatsakis (Apr 09 2019 at 17:17, on Zulip):

but that depends on how yucky it was :)

nikomatsakis (Apr 09 2019 at 17:17, on Zulip):

also, I think I heard somewhere something about performance implications?

nikomatsakis (Apr 09 2019 at 17:17, on Zulip):

(though that mildly surprises me)

davidtwco (Apr 09 2019 at 17:17, on Zulip):

It definitely felt like a yucky solution, but that might just be me. I can’t think of a better way.

davidtwco (Apr 09 2019 at 17:18, on Zulip):

also, I think I heard somewhere something about performance implications?

I don't remember anything like that, but I could just be being forgetful. I read that from the perspective of the PR impacting compiler performance.

Taylor Cramer (Apr 09 2019 at 17:20, on Zulip):

@nikomatsakis we were discussing runtime performance implications in the issue (due to the generator size change and the delay before dropping)

nikomatsakis (Apr 09 2019 at 17:22, on Zulip):

@Taylor Cramer why did the generator get bigger? is that beacuse of the issue that @tmandry was working on?

nikomatsakis (Apr 09 2019 at 17:22, on Zulip):

i.e., just being inefficient in our layout?

davidtwco (Apr 09 2019 at 17:22, on Zulip):

The generator will capture the arguments that it previously didn't.

Taylor Cramer (Apr 09 2019 at 17:22, on Zulip):

No, because we have to actually store the arguments in the future in order to drop them

nikomatsakis (Apr 09 2019 at 17:22, on Zulip):

Yeah, but .. how many arguments do you have that are unused?

nikomatsakis (Apr 09 2019 at 17:22, on Zulip):

I guess you're saying this is a frequent occurrence?

Taylor Cramer (Apr 09 2019 at 17:23, on Zulip):

It will certainly happen when we have async fn in traits

nikomatsakis (Apr 09 2019 at 17:23, on Zulip):

Put another way, I would have expected that -- most of the time -- we would be capturing most of the arguments anyway.

nikomatsakis (Apr 09 2019 at 17:23, on Zulip):

Sure. I don't doubt it can happen.

Taylor Cramer (Apr 09 2019 at 17:23, on Zulip):

Today we only have free and inherent async fn so it makes no difference because we have no unused args

Taylor Cramer (Apr 09 2019 at 17:23, on Zulip):

but in the case where you don't have unused args this doesn't matter anyways :)

nikomatsakis (Apr 09 2019 at 17:24, on Zulip):

Put another way: I was operating under the assumption that this was a corner case. =) That doesn't make it unimportant per se.

nikomatsakis (Apr 09 2019 at 17:24, on Zulip):

Anyway, ok, I get it.

nikomatsakis (Apr 09 2019 at 17:24, on Zulip):

So, it's not that you measured this against existing code and found a large impact

nikomatsakis (Apr 09 2019 at 17:24, on Zulip):

But rather that you hypothesize the impact might be noticeable when we have traits and more frequently have unused parameters

Taylor Cramer (Apr 09 2019 at 17:24, on Zulip):

Yes.

nikomatsakis (Apr 09 2019 at 17:24, on Zulip):

(It's certainly true that -- most of the time -- drop has no side-effects, and we'd rather drop early)

Taylor Cramer (Apr 09 2019 at 17:25, on Zulip):

And where it does have side-effects, you'd often want them to happen before returning the future if you don't need the arg

nikomatsakis (Apr 09 2019 at 17:25, on Zulip):

As a random aside, I sometimes question whether it was wise to carry over the C++ design of "side-effectful destructors"

nikomatsakis (Apr 09 2019 at 17:25, on Zulip):

but oh well

nikomatsakis (Apr 09 2019 at 17:25, on Zulip):

a little late now!

Taylor Cramer (Apr 09 2019 at 17:25, on Zulip):

yeah, we've discussed that before

nikomatsakis (Apr 09 2019 at 17:25, on Zulip):

And where it does have side-effects, you'd often want them to happen before returning the future if you don't need the arg

this...seems unclear to me

nikomatsakis (Apr 09 2019 at 17:26, on Zulip):

but maybe

Taylor Cramer (Apr 09 2019 at 17:26, on Zulip):

There're a couple particular examples I could show, like closing the end of a channel etc.

Taylor Cramer (Apr 09 2019 at 17:26, on Zulip):

where it forces an extra round-trip through the kernel

nikomatsakis (Apr 09 2019 at 17:26, on Zulip):

Yeah, so this uncertainty sort of argues for the "don't stabilize a drop order yet" I was proposing earlier

Taylor Cramer (Apr 09 2019 at 17:26, on Zulip):

I don't know what that would mean in practice

Taylor Cramer (Apr 09 2019 at 17:27, on Zulip):

once we introduce something, it will be stabilized

nikomatsakis (Apr 09 2019 at 17:27, on Zulip):

it would mean that we check that all the arguments are used and captured

nikomatsakis (Apr 09 2019 at 17:27, on Zulip):

and we give a feature gate

tmandry (Apr 09 2019 at 17:27, on Zulip):

This may be a little out there, but I wonder if it's really the type implementing Drop that can tell us more about whether it can be dropped early

nikomatsakis (Apr 09 2019 at 17:27, on Zulip):

if any of them are not

Taylor Cramer (Apr 09 2019 at 17:27, on Zulip):

huh

Taylor Cramer (Apr 09 2019 at 17:27, on Zulip):

I actually don't hate that

nikomatsakis (Apr 09 2019 at 17:27, on Zulip):

This may be a little out there, but I wonder if it's really the type implementing Drop that can tell us more about whether it can be dropped early

(yes, we've considered this in the past)

Taylor Cramer (Apr 09 2019 at 17:27, on Zulip):

(the feature gate thing)

nikomatsakis (Apr 09 2019 at 17:27, on Zulip):

I actually don't hate that

I think that if the motivation is "we'd like more time to look at what happens in practice", it may make sense

Taylor Cramer (Apr 09 2019 at 17:27, on Zulip):

mhm

Taylor Cramer (Apr 09 2019 at 17:27, on Zulip):

And certainly there's no reason to do it today

Taylor Cramer (Apr 09 2019 at 17:28, on Zulip):

it's a bit of a shame for unimplemented!() functions

nikomatsakis (Apr 09 2019 at 17:28, on Zulip):

I would usually do something like

nikomatsakis (Apr 09 2019 at 17:28, on Zulip):

panic!("unimplemented {:?}", (arg0, arg1, arg2));

nikomatsakis (Apr 09 2019 at 17:28, on Zulip):

but yes :)

nikomatsakis (Apr 09 2019 at 17:29, on Zulip):

we wouldn't want this state of affairs permanently

nikomatsakis (Apr 09 2019 at 17:29, on Zulip):

I guess it depends on how much we really wonder what the best order is

Taylor Cramer (Apr 09 2019 at 17:30, on Zulip):

It was certainly unresolved at the conclusion of the last lang mtg

nikomatsakis (Apr 09 2019 at 17:32, on Zulip):

Yeah. I can see why.

nikomatsakis (Apr 09 2019 at 17:32, on Zulip):

A bit more complex than I initially thought.

Taylor Cramer (Apr 09 2019 at 17:33, on Zulip):

@nikomatsakis I feel like it'd be easy to reach agreement on the feature-gate solution

nikomatsakis (Apr 09 2019 at 17:34, on Zulip):

Maybe so. I'm not sure, but it's worth talking ove.

Taylor Cramer (Apr 09 2019 at 17:34, on Zulip):

although I could see an argument that it contributes to the "unpolished" impression

Taylor Cramer (Apr 09 2019 at 17:34, on Zulip):

mhm

nikomatsakis (Apr 09 2019 at 17:34, on Zulip):

I think the question is whether this is something where empirical evidence / experience might be useful in resolving it.

nikomatsakis (Apr 09 2019 at 17:34, on Zulip):

although I could see an argument that it contributes to the "unpolished" impression

yes, this is the downside

nikomatsakis (Apr 09 2019 at 17:34, on Zulip):

on the other hand, I think that if it is not because "impl is hard" but beacuse "we want feedback", that's a different thing

tmandry (Apr 09 2019 at 17:35, on Zulip):

(also, making an arbitrary decision in the name of polish would not be a good answer to that :) )

nikomatsakis (Apr 09 2019 at 17:36, on Zulip):

it might be worth investigating how hard it would be to do the feature gate

tmandry (Apr 09 2019 at 17:38, on Zulip):

Quick update on #52924 before I have to run: Before we revised the optimization strategy I had changed a bunch of things to get codegen working with variant-ful generators. I'm now pulling these changes out before redoing the optimization itself. More info available in the thread

Taylor Cramer (Apr 09 2019 at 17:39, on Zulip):

Cool-- apart from that the remaining issues are all tied to surface syntax

Taylor Cramer (Apr 09 2019 at 17:40, on Zulip):

@nikomatsakis do you know what you want the next steps to be regarding resolving that issue?

Taylor Cramer (Apr 09 2019 at 17:40, on Zulip):

I feel like there hasn't been progress on it in a while, but maybe I haven't been following the right discussions

Taylor Cramer (Apr 09 2019 at 17:41, on Zulip):

Do you think it's worthwhile for me to go ahead and write up a PR implementing the "most likely" syntax?

Giles Cope (Apr 09 2019 at 17:41, on Zulip):

That would at least put the cat among the pigeons....

Taylor Cramer (Apr 09 2019 at 17:51, on Zulip):

@Giles Cope yeah, I don't think I would open a PR, but it seems possibly worthwhile to prepare

Taylor Cramer (Apr 09 2019 at 17:52, on Zulip):

ping @nikomatsakis thoughts on next steps here?

David Barsky (Apr 09 2019 at 17:54, on Zulip):

(Have been lurking here for a bit) Can you elaborate what the “most likely” syntax would be? the postfix await?

(I liked that one the most, but that's not important to the question.)

Taylor Cramer (Apr 09 2019 at 17:58, on Zulip):

@David Barsky no, I can't.

Taylor Cramer (Apr 09 2019 at 17:58, on Zulip):

I don't think that's appropriate to speculate on publicly, for the same reasons I said I wouldn't open a PR.

David Barsky (Apr 09 2019 at 17:59, on Zulip):

@Taylor Cramer No worries, I completely understand! I drafted that message before I saw “I don't think I would open a PR”, so my bad on missing that.

Giles Cope (Apr 09 2019 at 18:04, on Zulip):

Hopefully they will decide something soon. I had an async await question my mate posed me. He said async await in C# was terrible as you would by default re-join the same thread which very often leads them to deadlocks in the code. Is this something we need to worry about?

Nikon the Third (Apr 09 2019 at 18:16, on Zulip):

@Giles Cope I hope it is ok if I chime in here, but in .NET the behaviour that a task tries to resume on the same thread the await was called is a conscious decision made by Microsoft. You explicitly have to call ConfigureAwait(false) to allow the task to resume on a different thread. As long as Rust does not take the same road, these kind of deadlocks will not happen.

Giles Cope (Apr 09 2019 at 18:56, on Zulip):

Yeah, he said the clean async await codebases are now littered with .ConfigureAwait(false) everywhere. And the one or two places you forget are where the deadlock probably is. I was a little disheartened to hear of his experience.

nikomatsakis (Apr 09 2019 at 20:51, on Zulip):

@Taylor Cramer whoops, sorry, got stuck on another call and missed your pings -- I'll privmsg you

Last update: Nov 18 2019 at 01:50UTC