Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why allow async function, with no await or future? #4148

Closed
xdega opened this issue Nov 1, 2024 · 6 comments
Closed

Why allow async function, with no await or future? #4148

xdega opened this issue Nov 1, 2024 · 6 comments
Labels
question Further information is requested

Comments

@xdega
Copy link

xdega commented Nov 1, 2024

I have a pretty simple question (maybe it has a pretty simple answer?).

Is there ever a reason for a function to be async, when it doesn't await nor return a future?

For example, let's say I have this:

void foo() async {
  // do something not async
}

Shouldn't it be a default linting rule that the async in this case be noted as "unnecessary"?

It's entirely possible I am missing something, but at least 3-4 times this week, I have encountered this exact case, where we don't want the function to be async, there's no reason for it. Given how good the Dart linting is, it's shocking that this doesn't get called out. But again, does have me wondering if there's an actual legitimate case for this 🤔

This may be loosely related to the discussion here: #3571

@xdega xdega added the feature Proposed language feature that solves one or more problems label Nov 1, 2024
@jakemac53
Copy link
Contributor

Is there ever a reason for a function to be async, when it doesn't await nor return a future?

This is impossible, all async functions always return futures. Even if they are typed void or FutureOr.

String foo() async {
  return 'bar'
}

That function isn't valid, it is an error Functions marked 'async' must have a return type assignable to 'Future'.

Shouldn't it be a default linting rule that the async in this case be noted as "unnecessary"?

Sometimes you want a function to have an async return type even though it doesn't do anything async today. Maybe it is an override of an async method, or you want to allow overrides to be async, or you want to change your implementation to be async later on. The async modifier is the easiest way to return a future in this case.

@lrhn
Copy link
Member

lrhn commented Nov 1, 2024

What @jakemac53 says.
There one case where the async is unnecessary is off the function contains no await and it's return type is void.
It doesn't need the async and the caller doesn't need the returned Future.

So don't do that.
(The language doesn't care enough to disallow it. That would require more work than just saying "don't do that". It's only unnecessary, not harmful.)

@lrhn lrhn added question Further information is requested and removed feature Proposed language feature that solves one or more problems labels Nov 1, 2024
@munificent
Copy link
Member

Closing this because I think the question was answered.

@xdega
Copy link
Author

xdega commented Nov 2, 2024

What @jakemac53 says. There one case where the async is unnecessary is off the function contains no await and it's return type is void. It doesn't need the async and the caller doesn't need the returned Future.

So don't do that. (The language doesn't care enough to disallow it. That would require more work than just saying "don't do that". It's only unnecessary, not harmful.)

Apologies. My example was bad. This is precisely the case I was referring to.

I guess the answer would still be the same then, @munificent ?
That dart simply doesn't care in this case?

I also don't think it should be disallowed, but sure would be nice to have my linter catch it (often times it gets missed when modifying code that previously required async)

@jakemac53
Copy link
Contributor

There is a avoid_void_async https://dart.dev/tools/linter-rules/avoid_void_async which is similar.

@xdega
Copy link
Author

xdega commented Nov 2, 2024

There is a avoid_void_async https://dart.dev/tools/linter-rules/avoid_void_async which is similar.

That's actually really helpful for my case. Thanks for sharing. Can discuss with my team if we want to enforce it. That rule will at least make it more explicit, and likely not missed 🤣

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants