--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.
(FWIW, I can't think of a reason not to wait on a Future result. That means "I'm kicking off this async operation and I don't care when/if it ever completes". Even in tests/prototypes, it doesn't hurt to add "await" and ensure predictability.)
(Also apparently we don't give the "unused variable" warning for parameters. Who knew?)
On Thu, Sep 3, 2015 at 3:19 PM, 'John Messerly' via Dart Misc <mi...@dartlang.org> wrote:(FWIW, I can't think of a reason not to wait on a Future result. That means "I'm kicking off this async operation and I don't care when/if it ever completes". Even in tests/prototypes, it doesn't hurt to add "await" and ensure predictability.)
One example is main(). I think event handlers are another case where awaiting may not add value.
In rare cases, if you're building your own asynchrony primitives (what can I say? It happens.) you may know that the future's completion is tracked in some other way already.
I like Paul's suggestions of "_" or a ignore() function. We'd probably want to special-case main() too.
On Thu, Sep 3, 2015 at 3:13 PM, 'Paul Berry' via Dart Misc <mi...@dartlang.org> wrote:(Also apparently we don't give the "unused variable" warning for parameters. Who knew?)That way you can override a method or a pass a callback to something that passes it parameters even if you don't actually need to use them. :)Cheers!- bob
How about ignoring dropped futures in any non-async function?That is, only give hints if a future is dropped inside an async or async* function where awaiting it would be trivial.
print(someAsyncCall());
funcExpectsAFuture(someAsyncCall());
Future funcExpectsAFuture(var arg) {...}
Two other ideas for suppressing the warning:1. Assign the future to a local variable whose name is "_". The future isn't dropped since we assign it to a variable. And the "unused variable" hint is not a problem because we already suppress that hint when the name is "_". Disadvantage: you can only have one local called "_" per method.
Just curious, is the context for this discussion https://github.com/dart-lang/sdk/issues/24171?(FWIW, I can't think of a reason not to wait on a Future result. That means "I'm kicking off this async operation and I don't care when/if it ever completes". Even in tests/prototypes, it doesn't hurt to add "await" and ensure predictability.)
await callAsyncA(); await callAsyncB(); callAsyncC().then((e) => doSomething, onError: (e) => handleError); await callAsyncD();
Two other ideas for suppressing the warning:1. Assign the future to a local variable whose name is "_". The future isn't dropped since we assign it to a variable. And the "unused variable" hint is not a problem because we already suppress that hint when the name is "_". Disadvantage: you can only have one local called "_" per method.
2. Create a do-nothing function you can pass the future to when you really mean to ignore it:void ignoreFuture(Future _) {}
print(asyncCall());
One example is main(). I think event handlers are another case where awaiting may not add value.So for main, that's because there's code in the runtime that will wait for all pending operations. It's sort of like the system is adding a big "await" at the end of your main.
Not sure I follow the event handler point.
In rare cases, if you're building your own asynchrony primitives (what can I say? It happens.) you may know that the future's completion is tracked in some other way already.I guess in that case, you may not be using "async" in the first place?
How about ignoring dropped futures in any non-async function?That is, only give hints if a future is dropped inside an async or async* function where awaiting it would be trivial.
That would automatically handle the case of a non-async "main" function starting an otherwise async program.
I commented on the issue already.It is not about "I'm kicking off this async operation and I don't care when/if it ever completes"its about "I'm kicking off this async operation and care when it completes, but until then I'm doing something else, instead of just waiting"await callAsyncA(); await callAsyncB(); callAsyncC().then((e) => doSomething, onError: (e) => handleError); await callAsyncD();I can also add a timeout to the future to ensure it completes eventually.
On Fri, Sep 4, 2015 at 12:01 AM, Günter Zöchbauer <gzo...@gmail.com> wrote:I commented on the issue already.It is not about "I'm kicking off this async operation and I don't care when/if it ever completes"its about "I'm kicking off this async operation and care when it completes, but until then I'm doing something else, instead of just waiting"await callAsyncA(); await callAsyncB(); callAsyncC().then((e) => doSomething, onError: (e) => handleError); await callAsyncD();I can also add a timeout to the future to ensure it completes eventually.This example would be fine. Since the future returned by callAsyncC() is used (its .then() is invoked), there should be no hint here.
The only case where you'd get a hint is when a future is consigned to the void—when the Future result of an expression in statement position is discarded.- bob
Except that then() also returns a future, and *that* future is getting ignored.
- bob