Stream: wg-async-foundations

Topic: #54716 drop order future compat


centril (Apr 18 2019 at 15:05, on Zulip):

That's where we introduce the statement into the HIR, but I construct it in the parser because I need to use it in name resolution and a few other places.

@davidtwco @nikomatsakis so could you leave a "fake pattern" in place in HIR to run type inference on that pattern later?

centril (Apr 18 2019 at 15:06, on Zulip):

(including when APIT, arg: impl Trait is involved)

centril (Apr 18 2019 at 15:06, on Zulip):

Otherwise it seems to me that we cannot have async fn foo(Bar(x: usize)) { ... } and determine the type of the first formal parameter

centril (Apr 18 2019 at 15:07, on Zulip):

since type inference, as far as I know, is done after lowering

centril (Apr 18 2019 at 15:10, on Zulip):

So you need to have something async fn foo(Bar(x: usize)) { ... } where Bar(x: usize) is marked as a "fake pattern" so that you can run type inference on Bar(x: usize) then

centril (Apr 18 2019 at 15:15, on Zulip):

on the other hand, since it is done later, it also makes the async fn foo(Bar(x: usize)) { ... } problem go away since type inference has already been done at that point

centril (Apr 18 2019 at 15:16, on Zulip):

@davidtwco yea, my question is mostly directed at @nikomatsakis, who is afaik very familiar with inference, no worries :slight_smile:

centril (Apr 18 2019 at 15:21, on Zulip):

@davidtwco A thought... can you "gather" the bindings into a tuple and then "scatter" them inside the async { ... } block? e.g.

async fn foo($pat: $type) {
    async {
        let $scatter_bindings_of($pat) = $gather_bindings_of($pat);
    }
}
centril (Apr 18 2019 at 15:23, on Zulip):

if you can do this then $pat: $type remains in place and so it should also work with inference for async fn foo($pat) without $type.

davidtwco (Apr 18 2019 at 15:28, on Zulip):

if you can do this then $pat: $type remains in place and so it should also work with inference for async fn foo($pat) without $type.

I might be misunderstanding what you are suggesting, but I don't think that would resolve the type inference error that the current implementation hits. It isn't a genuine "there isn't enough information available to work it out", I'm pretty sure it's a bug due to my desugaring changes.

centril (Apr 18 2019 at 15:28, on Zulip):

@davidtwco I'm not discussing your inference problems

davidtwco (Apr 18 2019 at 15:28, on Zulip):

davidtwco I'm not discussing your inference problems

I definitely did misunderstand then.

centril (Apr 18 2019 at 15:29, on Zulip):

I'm discussing forward compatibility with not having $type directly available in the function signature such that you must infer it from $pat (not global type inference, all info is still available from $pat and the type parameters -- you don't need to look at the body..)

davidtwco (Apr 18 2019 at 15:30, on Zulip):

I'm discussing forward compatibility with not having $type directly available in the function signature such that you must infer it from $pat

I see. I'm just focusing on getting the current implementation working where types are provided in signatures for now.

centril (Apr 18 2019 at 15:33, on Zulip):

@davidtwco right; I just want to be sure that whatever you are doing doesn't make it impossible to omit $type in the future :slight_smile:

davidtwco (Apr 18 2019 at 15:40, on Zulip):

Is there an accepted RFC for that? I don't keep up with what RFCs there are to be implemented.

centril (Apr 18 2019 at 15:42, on Zulip):

@davidtwco no; it was part of the type ascription rfc but was later removed

davidtwco (Apr 18 2019 at 15:43, on Zulip):

I'm going to move some of these messages to another topic so I can keep the discussion in this one focused on the current implementation and put future compat discussion in another topic.

centril (Apr 18 2019 at 20:09, on Zulip):

Conclusion from a chat with Niko is that this seems surmountable in various ways

Last update: Nov 18 2019 at 02:00UTC