Stream: wg-async-foundations

Topic: inline-as-an-error

nikomatsakis (Sep 04 2019 at 19:27, on Zulip):

I agree that it's just a hint. The main reason to make it an error would be to eliminate bug reports and avoid confusion, since it has no real role in this position. I don't really care strongly enough to argue about it though. We could just close the bug as "wontfix"

nikomatsakis (Sep 04 2019 at 19:27, on Zulip):

That said, the definition of the #[inline] attribute presumably already has some rules about what sorts of items it can be applied to

nikomatsakis (Sep 04 2019 at 19:28, on Zulip):

It doesn't seem unreasonable for those rules to exclude async fn, just as they exclude (say) structs:

struct Foo { }

fn main() { }

gives an error

centril (Sep 05 2019 at 03:16, on Zulip):

I think struct and async fn are dissimilar. The error message says it cannot be applied to a function, but an async fn is a function. Indeed, with the desugaring based explanation of async fn, it does seem reasonable for #[inline] to essentially transfer to the desugared function. Whether it then has an effect or not is merely a quality-of-implementation issue.

I would be fine with a lint or something if this becomes a frequent source of reports but I am not convinced it will be.

simulacrum (Sep 05 2019 at 14:38, on Zulip):

In some sense an async fn is just a struct declaration though? Like, that's what happens when it's called

centril (Sep 05 2019 at 17:41, on Zulip):

@simulacrum that's the ~output of calling the async fn but it's still a function to be called

centril (Sep 05 2019 at 17:42, on Zulip):

async fns happen to be pure and all

simulacrum (Sep 05 2019 at 17:42, on Zulip):

hm, I guess that's true. Presumably then #[inline] will work similarly to inlining a constructor function

centril (Sep 05 2019 at 17:42, on Zulip):

yea I think that's a good way to think of it

simulacrum (Sep 05 2019 at 17:42, on Zulip):

(there is, I suppose, some parallel with asking for #[inline] on a tuple struct for which we generate fn Type(...))

Last update: Jul 16 2020 at 14:20UTC