[dart-misc] Re: Static checking for dropped futures

['Brian Wilkerson' via Dart Misc]

There are two ways that I can think of for handling false positives. One is
to carefully define the hint such that there won't be any false positives.
The other is to specify a way to tell the analyzer that you know what
you're doing. The first is almost always better.

For the case of dropped futures, I can't think of a way to avoid false
positives. As far as I know the cases where it's ok to not wait for the
future look (statically) just like the case where it isn't. (If that's not
true, I'd love to hear what the rules should be for deciding when to
produce a hint.) That leaves me thinking we need some way to tell the
analyzer when it's ok.

We can do that by extending the language (something like a "don't wait for"
keyword where the "await" keyword would have been) or by using annotations.
I really don't want a separate keyword, and I doubt anyone else does either
:-).

The problem with annotations, though, is their granularity. It seems
plausible that users could have a single method that invokes multiple
future-returning functions/methods and that only one of those invocations
should be allowed to be dropped. Unfortunately, as things stand today, you
can't annotate expressions. You can't even annotate statements, though that
would probably be sufficient because I expect that the invocation would
almost always be the top-level expression in an expression statement.

So, is there a better solution that I'm not thinking of?

Brian

['Paul Berry' via Dart Misc]

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 _) {}

This works to suppress the warning because the analyzer only analyzes one
function at a time, so at the call site it has no way of knowing that
ignoreFuture() will drop the future. And the declaration of ignoreFuture
is also warning-free because the variable's name is "_". (Also apparently
we don't give the "unused variable" warning for parameters. Who knew?)
Incidentally, we could always add a definition of "ignoreFuture" to
dart:async as a convenience to users.

Both of these approaches have zero run-time overhead because they are
easily optimized away by the VM (and presumably also dart2js).

Paul

On Thu, 3 Sep 2015 at 14:58 'Brian Wilkerson' via Dart Misc <

Post by 'Brian Wilkerson' via Dart Misc
There are two ways that I can think of for handling false positives. One
is to carefully define the hint such that there won't be any false
positives. The other is to specify a way to tell the analyzer that you know
what you're doing. The first is almost always better.
For the case of dropped futures, I can't think of a way to avoid false
positives. As far as I know the cases where it's ok to not wait for the
future look (statically) just like the case where it isn't. (If that's not
true, I'd love to hear what the rules should be for deciding when to
produce a hint.) That leaves me thinking we need some way to tell the
analyzer when it's ok.
We can do that by extending the language (something like a "don't wait
for" keyword where the "await" keyword would have been) or by using
annotations. I really don't want a separate keyword, and I doubt anyone
else does either :-).
The problem with annotations, though, is their granularity. It seems
plausible that users could have a single method that invokes multiple
future-returning functions/methods and that only one of those invocations
should be allowed to be dropped. Unfortunately, as things stand today, you
can't annotate expressions. You can't even annotate statements, though that
would probably be sufficient because I expect that the invocation would
almost always be the top-level expression in an expression statement.
So, is there a better solution that I'm not thinking of?
Brian
--
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

['John Messerly' via Dart Misc]

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.)



On Thu, Sep 3, 2015 at 3:13 PM, 'Paul Berry' via Dart Misc <

Post by 'Paul Berry' via Dart Misc
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
void ignoreFuture(Future _) {}
This works to suppress the warning because the analyzer only analyzes one
function at a time, so at the call site it has no way of knowing that
ignoreFuture() will drop the future. And the declaration of ignoreFuture
is also warning-free because the variable's name is "_". (Also apparently
we don't give the "unused variable" warning for parameters. Who knew?)
Incidentally, we could always add a definition of "ignoreFuture" to
dart:async as a convenience to users.
Both of these approaches have zero run-time overhead because they are
easily optimized away by the VM (and presumably also dart2js).
Paul
On Thu, 3 Sep 2015 at 14:58 'Brian Wilkerson' via Dart Misc <

Post by 'Brian Wilkerson' via Dart Misc
There are two ways that I can think of for handling false positives. One
is to carefully define the hint such that there won't be any false
positives. The other is to specify a way to tell the analyzer that you know
what you're doing. The first is almost always better.
For the case of dropped futures, I can't think of a way to avoid false
positives. As far as I know the cases where it's ok to not wait for the
future look (statically) just like the case where it isn't. (If that's not
true, I'd love to hear what the rules should be for deciding when to
produce a hint.) That leaves me thinking we need some way to tell the
analyzer when it's ok.
We can do that by extending the language (something like a "don't wait
for" keyword where the "await" keyword would have been) or by using
annotations. I really don't want a separate keyword, and I doubt anyone
else does either :-).
The problem with annotations, though, is their granularity. It seems
plausible that users could have a single method that invokes multiple
future-returning functions/methods and that only one of those invocations
should be allowed to be dropped. Unfortunately, as things stand today, you
can't annotate expressions. You can't even annotate statements, though that
would probably be sufficient because I expect that the invocation would
almost always be the top-level expression in an expression statement.
So, is there a better solution that I'm not thinking of?
Brian
--
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

--
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

['Brian Wilkerson' via Dart Misc]

John,

Just curious, is the context for this discussion

Post by 'John Messerly' via Dart Misc
https://github.com/dart-lang/sdk/issues/24171?

Yes, and no. I actually started it in response to the DEP committee meeting
notes, but the issue was created before the meeting and then the same topic
was discussed.

Brian

['Brian Slesinsky' via Dart Misc]

Fire-and-forget is useful when the notification happens in a different way.
(For example, one function fires off some tasks and a different function
handles completion via some internal mechanism rather than the future.)

On Thu, Sep 3, 2015 at 3:19 PM, 'John Messerly' via Dart Misc <
***@dartlang.org> wrote:

(FWIW, I can't think of a reason not to wait on a Future result. That means

Post by 'John Messerly' via Dart Misc
"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.)

['Bob Nystrom' via Dart Misc]

On Thu, Sep 3, 2015 at 3:19 PM, 'John Messerly' via Dart Misc <

Post by 'John Messerly' via Dart Misc
(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 <

Post by 'John Messerly' via Dart Misc
(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

['John Messerly' via Dart Misc]

On Thu, Sep 3, 2015 at 3:30 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Brian Slesinsky' via Dart Misc
On Thu, Sep 3, 2015 at 3:19 PM, 'John Messerly' via Dart Misc <

Post by 'John Messerly' via Dart Misc
(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.

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

Post by 'Brian Slesinsky' via Dart Misc
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?

I like Paul's suggestions of "_" or a ignore() function. We'd probably want

Post by 'Brian Slesinsky' via Dart Misc
to special-case main() too.

seems reasonable to me

Post by 'Brian Slesinsky' via Dart Misc
On Thu, Sep 3, 2015 at 3:13 PM, 'Paul Berry' via Dart Misc <

Post by 'John Messerly' via Dart Misc
(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
--
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

['Lasse R.H. Nielsen' via Dart Misc]

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.

/L


On Fri, Sep 4, 2015 at 12:38 AM, 'John Messerly' via Dart Misc <

Post by 'John Messerly' via Dart Misc
On Thu, Sep 3, 2015 at 3:30 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Brian Slesinsky' via Dart Misc
On Thu, Sep 3, 2015 at 3:19 PM, 'John Messerly' via Dart Misc <

Post by 'John Messerly' via Dart Misc
(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.

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

Post by 'Brian Slesinsky' via Dart Misc
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?
I like Paul's suggestions of "_" or a ignore() function. We'd probably

Post by 'Brian Slesinsky' via Dart Misc
want to special-case main() too.

seems reasonable to me

Post by 'Brian Slesinsky' via Dart Misc
On Thu, Sep 3, 2015 at 3:13 PM, 'Paul Berry' via Dart Misc <

Post by 'John Messerly' via Dart Misc
(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
--
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

--
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

--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

[Günter Zöchbauer]

On Friday, September 4, 2015 at 8:14:58 AM UTC+2, Lasse Reichstein Holst

Post by 'Lasse R.H. Nielsen' via Dart Misc
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.

I assumed this topic is for async/async* functions only anyway.
A way to silence the hint in async/async* functions is still necessary.
Assigning to _ would be fine for me.

What about inline calls like
print(someAsyncCall());

In this case a hint would be great
but when I want to pass the future I would probably get a hint
funcExpectsAFuture(someAsyncCall());

How could the analyzer distinguish between these two. funcExpectsAFuture
could look like
Future funcExpectsAFuture(var arg) {...}


That would automatically handle the case of a non-async "main" function

Post by 'Lasse R.H. Nielsen' via Dart Misc
starting an otherwise async program.
/L
On Fri, Sep 4, 2015 at 12:38 AM, 'John Messerly' via Dart Misc <

Post by 'John Messerly' via Dart Misc
On Thu, Sep 3, 2015 at 3:30 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Brian Slesinsky' via Dart Misc
On Thu, Sep 3, 2015 at 3:19 PM, 'John Messerly' via Dart Misc <

Post by 'John Messerly' via Dart Misc
(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.

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

Post by 'Brian Slesinsky' via Dart Misc
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?
I like Paul's suggestions of "_" or a ignore() function. We'd probably

Post by 'Brian Slesinsky' via Dart Misc
want to special-case main() too.

seems reasonable to me

Post by 'Brian Slesinsky' via Dart Misc
On Thu, Sep 3, 2015 at 3:13 PM, 'Paul Berry' via Dart Misc <

Post by 'John Messerly' via Dart Misc
(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
--
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

--
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

--
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

['Bob Nystrom' via Dart Misc]

On Thu, Sep 3, 2015 at 3:38 PM, 'John Messerly' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
One example is main(). I think event handlers are another case where

Post by 'Bob Nystrom' via Dart Misc
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.

Right.

Post by 'Bob Nystrom' via Dart Misc
Not sure I follow the event handler point.

This is what I've *heard* but I don't have much first-hand experience here.
But something like a DOM event handler is sort of like a mini-main(). If
you kick off some asynchronous action in response to, say, a mouse down,
you don't really need *the event handler itself* to wait for completion.
(It can't anyway, since the underlying machinery calling your event handler
doesn't check to see if you returned a future.)

Post by 'Bob Nystrom' via Dart Misc
In rare cases, if you're building your own asynchrony primitives (what can

Post by 'Bob Nystrom' via Dart Misc
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?

Ah, good point!

On Thu, Sep 3, 2015 at 11:14 PM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
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.

Brilliant. This gives us a much better backwards compatibility story too.
Since most older code isn't using async, false positives won't appear there.

Cheers!

- bob

[Günter Zöchbauer]

Post by 'John Messerly' via Dart Misc
Just curious, is the context for this discussion
https://github.com/dart-lang/sdk/issues/24171
<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdart-lang%2Fsdk%2Fissues%2F24171&sa=D&sntz=1&usg=AFQjCNFGAqC_NGNRYSs5qJfhaf4YNN6MKA>
?
(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.)

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.

Post by 'John Messerly' via Dart Misc
On Thu, Sep 3, 2015 at 3:13 PM, 'Paul Berry' via Dart Misc <

Post by 'Paul Berry' via Dart Misc
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
void ignoreFuture(Future _) {}
This works to suppress the warning because the analyzer only analyzes one
function at a time, so at the call site it has no way of knowing that
ignoreFuture() will drop the future. And the declaration of ignoreFuture
is also warning-free because the variable's name is "_". (Also apparently
we don't give the "unused variable" warning for parameters. Who knew?)
Incidentally, we could always add a definition of "ignoreFuture" to
dart:async as a convenience to users.
Both of these approaches have zero run-time overhead because they are
easily optimized away by the VM (and presumably also dart2js).
Paul
On Thu, 3 Sep 2015 at 14:58 'Brian Wilkerson' via Dart Misc <

Post by 'Brian Wilkerson' via Dart Misc
There are two ways that I can think of for handling false positives. One
is to carefully define the hint such that there won't be any false
positives. The other is to specify a way to tell the analyzer that you know
what you're doing. The first is almost always better.
For the case of dropped futures, I can't think of a way to avoid false
positives. As far as I know the cases where it's ok to not wait for the
future look (statically) just like the case where it isn't. (If that's not
true, I'd love to hear what the rules should be for deciding when to
produce a hint.) That leaves me thinking we need some way to tell the
analyzer when it's ok.
We can do that by extending the language (something like a "don't wait
for" keyword where the "await" keyword would have been) or by using
annotations. I really don't want a separate keyword, and I doubt anyone
else does either :-).
The problem with annotations, though, is their granularity. It seems
plausible that users could have a single method that invokes multiple
future-returning functions/methods and that only one of those invocations
should be allowed to be dropped. Unfortunately, as things stand today, you
can't annotate expressions. You can't even annotate statements, though that
would probably be sufficient because I expect that the invocation would
almost always be the top-level expression in an expression statement.
So, is there a better solution that I'm not thinking of?
Brian
--
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

--
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

['Bob Nystrom' via Dart Misc]

Post by Günter Zöchbauer
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

['Paul Berry' via Dart Misc]

Post by 'Bob Nystrom' via Dart Misc

Post by Günter Zöchbauer
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.

Except that then() also returns a future, and *that* future is getting
ignored.

Post by 'Bob Nystrom' via Dart Misc
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
--
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

['Bob Nystrom' via Dart Misc]

On Fri, Sep 4, 2015 at 9:36 AM, 'Paul Berry' via Dart Misc <

Post by 'Paul Berry' via Dart Misc
Except that then() also returns a future, and *that* future is getting
ignored.

Crap.

<shakes first angrily at the sky>

- bob

[Günter Zöchbauer]

Post by 'Bob Nystrom' via Dart Misc

Post by Günter Zöchbauer
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.

the future returned by `callAsyncC()` is used but the future returned by
`then` or explained differently, the future returned by the entire
statement, is still consigned to the void.
In one case I might want to wait for its completion, in another I don't
care.

Post by 'Bob Nystrom' via Dart Misc
- bob

['Brian Slesinsky' via Dart Misc]

I was just going to suggest '_' myself:

var _ = await something();

Here, '_' is a special variable name that indicates a deliberately unused
variable.

I vaguely recall that there's a language where '_' is treated specially as
an ignored value in a pattern match. I imagine that in Dart that could that
being useful for an event handler where you're deliberately ignore some
parameters. So, you should be able to use '_' more than once as a parameter
name for unused parameters in a function, and it shouldn't complain.

But even without extra-special treatment, it's still a useful convention.


On Thu, Sep 3, 2015 at 3:13 PM, 'Paul Berry' via Dart Misc <

Post by 'Paul Berry' via Dart Misc
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
void ignoreFuture(Future _) {}
This works to suppress the warning because the analyzer only analyzes one
function at a time, so at the call site it has no way of knowing that
ignoreFuture() will drop the future. And the declaration of ignoreFuture
is also warning-free because the variable's name is "_". (Also apparently
we don't give the "unused variable" warning for parameters. Who knew?)
Incidentally, we could always add a definition of "ignoreFuture" to
dart:async as a convenience to users.
Both of these approaches have zero run-time overhead because they are
easily optimized away by the VM (and presumably also dart2js).
Paul
On Thu, 3 Sep 2015 at 14:58 'Brian Wilkerson' via Dart Misc <

Post by 'Brian Wilkerson' via Dart Misc
There are two ways that I can think of for handling false positives. One
is to carefully define the hint such that there won't be any false
positives. The other is to specify a way to tell the analyzer that you know
what you're doing. The first is almost always better.
For the case of dropped futures, I can't think of a way to avoid false
positives. As far as I know the cases where it's ok to not wait for the
future look (statically) just like the case where it isn't. (If that's not
true, I'd love to hear what the rules should be for deciding when to
produce a hint.) That leaves me thinking we need some way to tell the
analyzer when it's ok.
We can do that by extending the language (something like a "don't wait
for" keyword where the "await" keyword would have been) or by using
annotations. I really don't want a separate keyword, and I doubt anyone
else does either :-).
The problem with annotations, though, is their granularity. It seems
plausible that users could have a single method that invokes multiple
future-returning functions/methods and that only one of those invocations
should be allowed to be dropped. Unfortunately, as things stand today, you
can't annotate expressions. You can't even annotate statements, though that
would probably be sufficient because I expect that the invocation would
almost always be the top-level expression in an expression statement.
So, is there a better solution that I'm not thinking of?
Brian
--
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

--
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

[Günter Zöchbauer]

Post by 'Paul Berry' via Dart Misc
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.

Assigning to a local variable "_" more than once shouldn't cause any
problems, should it?

Post by 'Paul Berry' via Dart Misc
2. Create a do-nothing function you can pass the future to when you really
void ignoreFuture(Future _) {}
This works to suppress the warning because the analyzer only analyzes one
function at a time, so at the call site it has no way of knowing that
ignoreFuture() will drop the future. And the declaration of ignoreFuture
is also warning-free because the variable's name is "_". (Also apparently
we don't give the "unused variable" warning for parameters. Who knew?)
Incidentally, we could always add a definition of "ignoreFuture" to
dart:async as a convenience to users.
Both of these approaches have zero run-time overhead because they are
easily optimized away by the VM (and presumably also dart2js).
Paul
On Thu, 3 Sep 2015 at 14:58 'Brian Wilkerson' via Dart Misc <

Post by 'Brian Wilkerson' via Dart Misc
There are two ways that I can think of for handling false positives. One
is to carefully define the hint such that there won't be any false
positives. The other is to specify a way to tell the analyzer that you know
what you're doing. The first is almost always better.
For the case of dropped futures, I can't think of a way to avoid false
positives. As far as I know the cases where it's ok to not wait for the
future look (statically) just like the case where it isn't. (If that's not
true, I'd love to hear what the rules should be for deciding when to
produce a hint.) That leaves me thinking we need some way to tell the
analyzer when it's ok.
We can do that by extending the language (something like a "don't wait
for" keyword where the "await" keyword would have been) or by using
annotations. I really don't want a separate keyword, and I doubt anyone
else does either :-).
The problem with annotations, though, is their granularity. It seems
plausible that users could have a single method that invokes multiple
future-returning functions/methods and that only one of those invocations
should be allowed to be dropped. Unfortunately, as things stand today, you
can't annotate expressions. You can't even annotate statements, though that
would probably be sufficient because I expect that the invocation would
almost always be the top-level expression in an expression statement.
So, is there a better solution that I'm not thinking of?
Brian
--
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

[Günter Zöchbauer]

Post by 'Paul Berry' via Dart Misc
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
void ignoreFuture(Future _) {}

print(asyncCall());

I would want a hint here. I probably don't want to print the Future.
This is even more important than at the beginning of a statement where a
missing `await` is easier spotted.

Post by 'Paul Berry' via Dart Misc
This works to suppress the warning because the analyzer only analyzes one
function at a time, so at the call site it has no way of knowing that
ignoreFuture() will drop the future. And the declaration of ignoreFuture
is also warning-free because the variable's name is "_". (Also apparently
we don't give the "unused variable" warning for parameters. Who knew?)
Incidentally, we could always add a definition of "ignoreFuture" to
dart:async as a convenience to users.
Both of these approaches have zero run-time overhead because they are
easily optimized away by the VM (and presumably also dart2js).
Paul
On Thu, 3 Sep 2015 at 14:58 'Brian Wilkerson' via Dart Misc <

Post by 'Brian Wilkerson' via Dart Misc
There are two ways that I can think of for handling false positives. One
is to carefully define the hint such that there won't be any false
positives. The other is to specify a way to tell the analyzer that you know
what you're doing. The first is almost always better.
For the case of dropped futures, I can't think of a way to avoid false
positives. As far as I know the cases where it's ok to not wait for the
future look (statically) just like the case where it isn't. (If that's not
true, I'd love to hear what the rules should be for deciding when to
produce a hint.) That leaves me thinking we need some way to tell the
analyzer when it's ok.
We can do that by extending the language (something like a "don't wait
for" keyword where the "await" keyword would have been) or by using
annotations. I really don't want a separate keyword, and I doubt anyone
else does either :-).
The problem with annotations, though, is their granularity. It seems
plausible that users could have a single method that invokes multiple
future-returning functions/methods and that only one of those invocations
should be allowed to be dropped. Unfortunately, as things stand today, you
can't annotate expressions. You can't even annotate statements, though that
would probably be sufficient because I expect that the invocation would
almost always be the top-level expression in an expression statement.
So, is there a better solution that I'm not thinking of?
Brian
--
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