Future.immediate() should still be async.

[munificent]

Currently, a future created using Future.immediate() will complete synchronously. That means code consuming futures has to be aware that operations that it chains of a future it receives may in fact run synchronously or they may do bad things.

For a concrete example, the unittest API will fail spectacularly if what it thinks is an async test completes synchronously.

To keep the semantics simple for consumers of futures, I believe they should always complete asynchronously. This means Future.immediate() should pump the message queue before completing.

If we do make this change, we should probably change the name of the constructor too, since it's no longer "immediate". I would either just use an unnamed constructor, or possibly "of": new Future.of(someValue);

[sethladd]

For the record, Microsoft added a setImmediate(): http://ie.microsoft.com/testdrive/Performance/setImmediateSorting/Default.html

[whesse]

This issue came up when people wanted a platform-independent way to do new Timer(0, func) or window.setTimeout(0, func). So there are two issues: the need for a Future.spawn() which creates a new asynchronous queued closure, and the fact that a synchronous Future.immediate() may be confusing and error prone.

So even if Future.immediate remains sync, there is still a request for Future.spawn (or Future.async, or Future.queue).

[sethladd]

cc @sigmundch.

[sigmundch]

As Bill mentioned we need a platform-independent [Timer]. We are finally starting the process of moving Timer out of io. Once that's available everywhere, we will have all calls to [then] execute asynchronously (I personally like the suggestion [of]).

[munificent]

I like "of" too.

[justinfagnani]

Using Timer isn't ideal, since on browsers it will take at least 4ms to complete. I filed 5691 for some type of deferred function mechanism, like setImmediate(), except that I think it's best if Futures complete in the current event loop. setImmediate() calls at the beginning of the next event loop.

---

Removed the owner.
Marked this as being blocked by #5691.

[sigmundch]

can we have an event that is 'at the end of this event loop'?

---

cc @justinfagnani.

[sigmundch]

ok never mind my earlier comment - I see that this is addressed in dartbug.com/5691

[sigmundch]

I believe this is now fixed with libv2 in the new 'dart:async' library.

---

cc @floitschG.
Added Fixed label.

[sethladd]

Do you mean runAsync ?

[sigmundch]

Sorry, I was mostly referring to comment #­1. I think what Bob was asking for in comment #­1 is covered by the Future.immediate and Future.of constructors. To cover what I mentioned in #­7 we would need something like runAsync, which I think is what's tracked in issue #1 and issue #0

[sethladd]

Just for everyone following along at home, Future.of() runs its callback now but makes the value available asynchronously. (as is my understanding?)

[DartBot]

This comment was originally written by pr...@gmail.com

---

That should satisfy issue #2705 then I think Seth.