why is there a restriction of fn main() on #[async_std::main]?
#17
Comments
|
We made However we should indeed retain any visibility modifiers, and the fact that we don't is a bug. If you'd like to send in a PR for that it'd be much appreciated! |
|
Ok great - will send a PR :)
…On Tue, 4 Aug 2020 at 11:46, Yoshua Wuyts ***@***.***> wrote:
We made async fn main only work with main because that's what it's
intended to be used for. If someone's using it somewhere else we figured
that would probably be a bug.
However we should indeed retain any visibility modifiers, and the fact
that we don't is a bug. If you'd like to send in a PR for that it'd be much
appreciated!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#17 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMRIARJCYDIP7WHNZVDP4TR67RJPANCNFSM4PSOQBVQ>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
More of a question really as this was surprising to me.
When using Tokio, you can add
#[tokio::main]to any fn and it works as expected, expanding out to eventually callingblock_onon a runtime.I can see https://github.com/async-rs/async-attributes/blob/master/src/lib.rs#L59 and wondered why this restriction is in place? if there's no technical limitation I will happily send a PR 👍
Also whilst here, I noticed that since you expect the attribute to always exist on
main, your code doesn't account for visibilty modifiers, eg:pub fn main()would lose thepubagain, if it's just
yet to be builtthen I'd love to help out.Many thanks for your time.
The text was updated successfully, but these errors were encountered: