Re: Future feedback

On Friday, May 17, 2013, Sean Hogan wrote:

> On 17/05/13 12:03 PM, Boris Zbarsky wrote:
>
>> On 5/16/13 6:52 PM, Sean Hogan wrote:
>>
>>> So what would be the problem if `setImmediate()` just appended to the
>>> futures task source?
>>>
>>
>> None per se, except to the extent that you want to have different
>> priority settings for setImmediate and futures or to the extent that you
>> want some sort of ordering guarantees between setImmediate and something
>> other than futures.
>>
>>
>
> From what I've read, the main demand for `setImmediate` (or equivalent) is
> for JS implementations of Promises, etc. Would anyone care if
>  `setImmediate` was implemented and then Futures (or whatever browsers
> settle on) got the same task source?
>

I don't know of any reason why setImmediate is required for
Futures/Promises. The most important contract is that resolution/callbacks
are provided *apparently* outside of synchronous control flow. That is to
say, if I .resolve() or .then(), the next line should not be able to
observe side-effects from side-effect generating callbacks. That contract
can be filled by any of end-of-microtask (Mutation Observers use this
today), setTimeout() (a full turn around the event loop with clamping), or
never-delivered.

I only support adding setImmediate() if it makes Object.observe() more sane.