On Sat, Apr 20, 2013 at 6:17 AM, Brendan Eich <brendan at mozilla.com> wrote:
> Tab Atkins Jr. wrote:
>> It would be so nice if JS had multiple return values, so we could let
>> cancellable future-returning APIs just return a naked resolver as
>> their second value,
>
> Hello, destructuring:
>
> let{  proxy, revoke}  = Proxy.revocable(target, handler);
>
>
> from http://wiki.ecmascript.org/doku.php?id=strawman:revokable_proxies. Or
> use an array pattern if you prefer.
>
> JIT'ing VMs can optimize these pretty easily to avoid object allocation.

Yeah, that's fine when you're explicitly invoking something that needs
to return two objects.

It's less fine when you have something like a hypothetical getJSON()
(future-returning XHR sugar), which can reasonably just return a
future, but which we also want to make cancellable.  Burdening *every*
call site with the need to pull out the future from the returned
object isn't great.  It also makes it hard to upgrade a call from
future-returning to cancellable-future-returning - you're pretty much
forced to use a variant function name. (In the case of cancellable
futures, we might be able to do it with an additional argument to the
relevant functions, instead.)

Lisp's multiple return values were nice in that regard - naive call
sites, or simply ones that only needed the primary values - could just
call it like a normal function that returned a single value.  Cluefull
call sites that *did* need the additional return values just used
values-list or multiple-value-bind to get all of the values.

This is probably just an idle wish, though, as destructuring takes a
lot of the wind out of the sails of multiple values. :/

~TJ

On Sat, Apr 20, 2013 at 6:17 AM, Brendan Eich <brendan at mozilla.com> wrote:
> Tab Atkins Jr. wrote:
>> It would be so nice if JS had multiple return values, so we could let
>> cancellable future-returning APIs just return a naked resolver as
>> their second value,
>
> Hello, destructuring:
>
> ```js
> let{  proxy, revoke}  = Proxy.revocable(target, handler);
> ```
>
>
> from http://wiki.ecmascript.org/doku.php?id=strawman:revokable_proxies. Or
> use an array pattern if you prefer.
>
> JIT'ing VMs can optimize these pretty easily to avoid object allocation.

Yeah, that's fine when you're explicitly invoking something that needs
to return two objects.

It's less fine when you have something like a hypothetical getJSON()
(future-returning XHR sugar), which can reasonably just return a
future, but which we also want to make cancellable.  Burdening *every*
call site with the need to pull out the future from the returned
object isn't great.  It also makes it hard to upgrade a call from
future-returning to cancellable-future-returning - you're pretty much
forced to use a variant function name. (In the case of cancellable
futures, we might be able to do it with an additional argument to the
relevant functions, instead.)

Lisp's multiple return values were nice in that regard - naive call
sites, or simply ones that only needed the primary values - could just
call it like a normal function that returned a single value.  Cluefull
call sites that *did* need the additional return values just used
values-list or multiple-value-bind to get all of the values.

This is probably just an idle wish, though, as destructuring takes a
lot of the wind out of the sails of multiple values. :/