Actually initial discussion which "inspires" me on this thoughts was in
[cancellation-tokens-related](/topic/cancel-promise-pattern-no-cancellable-promises)
topic. So here I didn't mean that it is impossible to implement that kind
of functionality on "home made" promises. I mean that it would be good to
have such functionality to "cancel"/"interrupt" execution flow of natively
generated promises, in particular to do some "cancellation" of ``async``
task represented by ``async function`` or "unsubscribe" callback in
construction ``consumer = provider.then(treatSomehow);`` and then write
``consumer.throw(new CancelationError("some reason"))`` instead of writing
 ``consumer.cancel()`` which might be "controversial" (whether we intend to
cancel provider too, in which form  we would like to do that (on which
"rail" that cancellation should be delivered? on success-rail, on
failure-rail or on some other extra-toxic cancellation-rail)). Ofcourse it
can be some very raw tools to do cancellation, but if they were present,
any "home made cancellation" would be much more doable and easy to
implement then it is now.

Regarding ``finally``/``return`` relationship I didn't mean that it is some
special feature of generators, instead, ofcourse I first of all check it on
regular functions (not only on js but in java too), and for me it was more
remarkable that ``return`` can be "replaced"  with ``break`` or
``continue`` by the means of ``finally`` block which is more interesting
case then replacing ``return`` with ``trow`` or vise versa (which ofcourse
also may lead to rather "strange" behavior and rear developer can guess
that and/or imagine that strange situation before someone else told him
about it). So putting that example with implicit ``return`` <-->
``continue`` replacement I didn't mean to show some "extra" behavior of
``generator.return()`` I only would like to highlight that ``function*``
generators implementation of ``.return`` is QUIT VALID and really simulates
``return`` behavior in place of ``yield`` instruction (without omitting any
strange "outcome" on execution flow which ``finally`` block may produce).
And it is actually a key difference with how bluebirdjs cancleation works
as follows from [bluebirdjs-cancellation](
http://bluebirdjs.com/docs/api/cancellation.html). There is assumed that
 cancellation action cause that "only active finally blocks (finally
callbacks) are executed" and then cancellation completes (there are no
chance to "override" cancellation propagation from finally callbacks in
that api) while in "real code" it is possible (and in generators to ...).

By the way in flavor of ``Promise.resolve`` and ``Promise.reject`` I would
rather "rename" ``Q.deferred`` into ``Promise.never``, in fact it would be
almost the same - factory of some promises that never completes it self by
its own but rather wait until someone pushes it from outside by the means
of abnormal ``.return`` or ``.throw``. Looks may be little bit strange, but
describes the thing nicely :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170114/c763e71f/attachment.html>

Actually initial discussion which "inspires" me on this thoughts was in
[cancellation-tokens-related](/topic/cancel-promise-pattern-no-cancellable-promises)
topic. So here I didn't mean that it is impossible to implement that kind
of functionality on "home made" promises. I mean that it would be good to
have such functionality to "cancel"/"interrupt" execution flow of natively
generated promises, in particular to do some "cancellation" of ``async``
task represented by ``async function`` or "unsubscribe" callback in
construction ``consumer = provider.then(treatSomehow);`` and then write
``consumer.throw(new CancelationError("some reason"))`` instead of writing
 ``consumer.cancel()`` which might be "controversial" (whether we intend to
cancel ``provider`` too, in which form  we would like to do that (on which
"rail" that cancellation should be delivered? on success-rail, on
failure-rail or on some other extra-toxic cancellation-rail)). Ofcourse it
can be some very raw tools to do cancellation, but if they were present,
any "home made cancellation" would be much more doable and easy to
implement then it is now.

Regarding ``finally``/``return`` relationship I didn't mean that it is some
special feature of generators, instead, ofcourse I first of all check it on
regular functions (not only on js but in java too), and for me it was more
remarkable that ``return`` can be "replaced"  with ``break`` or
``continue`` by the means of ``finally`` block which is more interesting
case then replacing ``return`` with ``trow`` or vise versa (which ofcourse
also may lead to rather "strange" behavior and rare developer can guess
that and/or imagine that strange situation before someone else told him
about it). So putting that example with implicit ``return`` <-->
``continue`` replacement I didn't mean to show some "extra" behavior of
``generator.return()`` I only would like to highlight that ``function*``
generators implementation of ``.return`` is QUIT VALID and really simulates
``return`` behavior in place of ``yield`` instruction (without omitting any
strange "outcome" on execution flow which ``finally`` block may produce).
And it is actually one of key differences with how bluebirdjs cancleation works
as follows from [bluebirdjs-cancellation](
http://bluebirdjs.com/docs/api/cancellation.html). There is assumed that
 cancellation action cause that "only active finally blocks (finally
callbacks) are executed" and then cancellation completes (there are no
chance to "override" cancellation propagation from finally callbacks in
that api) while in "real code" it is possible (and in generators to ...).

By the way in flavor of ``Promise.resolve`` and ``Promise.reject`` I would
rather "rename" ``Q.deferred`` into ``Promise.never``, in fact it would be
almost the same - factory of some promises that never completes it self by
its own but rather wait until someone pushes it from outside by the means
of abnormal ``.return`` or ``.throw``. It looks maybe little bit strange, but
describes the thing nicely :)

Actually initial discussion which "inspires" me on this thoughts was in
[cancellation-tokens-related](/topic/cancel-promise-pattern-no-cancellable-promises)
topic. So here I didn't mean that it is impossible to implement that kind
of functionality on "home made" promises. I mean that it would be good to
have such functionality to "cancel"/"interrupt" execution flow of natively
generated promises, in particular to do some "cancellation" of ``async``
task represented by ``async function`` or "unsubscribe" callback in
construction ``consumer = provider.then(treatSomehow);`` and then write
``consumer.throw(new CancelationError("some reason"))`` instead of writing
 ``consumer.cancel()`` which might be "controversial" (whether we intend to
cancel ``provider`` too, in which form  we would like to do that (on which
"rail" that cancellation should be delivered? on success-rail, on
failure-rail or on some other extra-toxic cancellation-rail)). Ofcourse it
can be some very raw tools to do cancellation, but if they were present,
any "home made cancellation" would be much more doable and easy to
implement then it is now.

Regarding ``finally``/``return`` relationship I didn't mean that it is some
special feature of generators, instead, ofcourse I first of all check it on
regular functions (not only on js but in java too), and for me it was more
remarkable that ``return`` can be "replaced"  with ``break`` or
``continue`` by the means of ``finally`` block which is more interesting
case then replacing ``return`` with ``trow`` or vise versa (which ofcourse
also may lead to rather "strange" behavior and rare developer can guess
that and/or imagine that strange situation before someone else told him
about it). So putting that example with implicit ``return`` <-->
``continue`` replacement I didn't mean to show some "extra" behavior of
``generator.return()`` I only would like to highlight that ``function*``
generators implementation of ``.return`` is QUIT VALID and really simulates
``return`` behavior in place of ``yield`` instruction (without omitting any
strange "outcome" on execution flow which ``finally`` block may produce).
And it is actually one of key differences with how bluebirdjs cancleation works
as follows from [bluebirdjs-cancellation](
http://bluebirdjs.com/docs/api/cancellation.html). There is assumed that
 cancellation action cause that "only active finally blocks (finally
callbacks) are executed" and then cancellation completes (there are no
chance to "override" cancellation propagation from finally callbacks in
that api) while in "real code" it is possible (and in generators to ...).

By the way in flavor of ``Promise.resolve`` and ``Promise.reject`` I would
rather "rename" ``Q.deferred`` into ``Promise.never``, in fact it would be
almost the same - factory of some promises that never completes it self by
its own but rather wait until someone pushes it from outside by the means
of abnormal ``.return`` or ``.throw``. It looks may be little bit strange, but
describes the thing nicely :)

Actually initial discussion which "inspires" me on this thoughts was in
[cancellation-tokens-related](/topic/cancel-promise-pattern-no-cancellable-promises)
topic. So here I didn't mean that it is impossible to implement that kind
of functionality on "home made" promises. I mean that it would be good to
have such functionality to "cancel"/"interrupt" execution flow of natively
generated promises, in particular to do some "cancellation" of ``async``
task represented by ``async function`` or "unsubscribe" callback in
construction ``consumer = provider.then(treatSomehow);`` and then write
``consumer.throw(new CancelationError("some reason"))`` instead of writing
 ``consumer.cancel()`` which might be "controversial" (whether we intend to
cancel ``provider`` too, in which form  we would like to do that (on which
"rail" that cancellation should be delivered? on success-rail, on
failure-rail or on some other extra-toxic cancellation-rail)). Ofcourse it
can be some very raw tools to do cancellation, but if they were present,
any "home made cancellation" would be much more doable and easy to
implement then it is now.

Regarding ``finally``/``return`` relationship I didn't mean that it is some
special feature of generators, instead, ofcourse I first of all check it on
regular functions (not only on js but in java too), and for me it was more
remarkable that ``return`` can be "replaced"  with ``break`` or
``continue`` by the means of ``finally`` block which is more interesting
case then replacing ``return`` with ``trow`` or vise versa (which ofcourse
also may lead to rather "strange" behavior and rare developer can guess
that and/or imagine that strange situation before someone else told him
about it). So putting that example with implicit ``return`` <-->
``continue`` replacement I didn't mean to show some "extra" behavior of
``generator.return()`` I only would like to highlight that ``function*``
generators implementation of ``.return`` is QUIT VALID and really simulates
``return`` behavior in place of ``yield`` instruction (without omitting any
strange "outcome" on execution flow which ``finally`` block may produce).
And it is actually one of key differences with how bluebirdjs cancleation works
as follows from [bluebirdjs-cancellation](
http://bluebirdjs.com/docs/api/cancellation.html). There is assumed that
 cancellation action cause that "only active finally blocks (finally
callbacks) are executed" and then cancellation completes (there are no
chance to "override" cancellation propagation from finally callbacks in
that api) while in "real code" it is possible (and in generators to ...).

By the way in flavor of ``Promise.resolve`` and ``Promise.reject`` I would
rather "rename" ``Q.deferred`` into ``Promise.never``, in fact it would be
almost the same - factory of some promises that never completes it self by
its own but rather wait until someone pushes it from outside by the means
of abnormal ``.return`` or ``.throw``. Looks may be little bit strange, but
describes the thing nicely :)

Actually initial discussion which "inspires" me on this thoughts was in
[cancellation-tokens-related](/topic/cancel-promise-pattern-no-cancellable-promises)
topic. So here I didn't mean that it is impossible to implement that kind
of functionality on "home made" promises. I mean that it would be good to
have such functionality to "cancel"/"interrupt" execution flow of natively
generated promises, in particular to do some "cancellation" of ``async``
task represented by ``async function`` or "unsubscribe" callback in
construction ``consumer = provider.then(treatSomehow);`` and then write
``consumer.throw(new CancelationError("some reason"))`` instead of writing
 ``consumer.cancel()`` which might be "controversial" (whether we intend to
cancel ``provider`` too, in which form  we would like to do that (on which
"rail" that cancellation should be delivered? on success-rail, on
failure-rail or on some other extra-toxic cancellation-rail)). Ofcourse it
can be some very raw tools to do cancellation, but if they were present,
any "home made cancellation" would be much more doable and easy to
implement then it is now.

Regarding ``finally``/``return`` relationship I didn't mean that it is some
special feature of generators, instead, ofcourse I first of all check it on
regular functions (not only on js but in java too), and for me it was more
remarkable that ``return`` can be "replaced"  with ``break`` or
``continue`` by the means of ``finally`` block which is more interesting
case then replacing ``return`` with ``trow`` or vise versa (which ofcourse
also may lead to rather "strange" behavior and rarу developer can guess
that and/or imagine that strange situation before someone else told him
about it). So putting that example with implicit ``return`` <-->
``continue`` replacement I didn't mean to show some "extra" behavior of
``generator.return()`` I only would like to highlight that ``function*``
generators implementation of ``.return`` is QUIT VALID and really simulates
``return`` behavior in place of ``yield`` instruction (without omitting any
strange "outcome" on execution flow which ``finally`` block may produce).
And it is actually one of key differences with how bluebirdjs cancleation works
as follows from [bluebirdjs-cancellation](
http://bluebirdjs.com/docs/api/cancellation.html). There is assumed that
 cancellation action cause that "only active finally blocks (finally
callbacks) are executed" and then cancellation completes (there are no
chance to "override" cancellation propagation from finally callbacks in
that api) while in "real code" it is possible (and in generators to ...).

By the way in flavor of ``Promise.resolve`` and ``Promise.reject`` I would
rather "rename" ``Q.deferred`` into ``Promise.never``, in fact it would be
almost the same - factory of some promises that never completes it self by
its own but rather wait until someone pushes it from outside by the means
of abnormal ``.return`` or ``.throw``. Looks may be little bit strange, but
describes the thing nicely :)

Actually initial discussion which "inspires" me on this thoughts was in
[cancellation-tokens-related](/topic/cancel-promise-pattern-no-cancellable-promises)
topic. So here I didn't mean that it is impossible to implement that kind
of functionality on "home made" promises. I mean that it would be good to
have such functionality to "cancel"/"interrupt" execution flow of natively
generated promises, in particular to do some "cancellation" of ``async``
task represented by ``async function`` or "unsubscribe" callback in
construction ``consumer = provider.then(treatSomehow);`` and then write
``consumer.throw(new CancelationError("some reason"))`` instead of writing
 ``consumer.cancel()`` which might be "controversial" (whether we intend to
cancel ``provider`` too, in which form  we would like to do that (on which
"rail" that cancellation should be delivered? on success-rail, on
failure-rail or on some other extra-toxic cancellation-rail)). Ofcourse it
can be some very raw tools to do cancellation, but if they were present,
any "home made cancellation" would be much more doable and easy to
implement then it is now.

Regarding ``finally``/``return`` relationship I didn't mean that it is some
special feature of generators, instead, ofcourse I first of all check it on
regular functions (not only on js but in java too), and for me it was more
remarkable that ``return`` can be "replaced"  with ``break`` or
``continue`` by the means of ``finally`` block which is more interesting
case then replacing ``return`` with ``trow`` or vise versa (which ofcourse
also may lead to rather "strange" behavior and rear developer can guess
that and/or imagine that strange situation before someone else told him
about it). So putting that example with implicit ``return`` <-->
``continue`` replacement I didn't mean to show some "extra" behavior of
``generator.return()`` I only would like to highlight that ``function*``
generators implementation of ``.return`` is QUIT VALID and really simulates
``return`` behavior in place of ``yield`` instruction (without omitting any
strange "outcome" on execution flow which ``finally`` block may produce).
And it is actually one of key differences with how bluebirdjs cancleation works
as follows from [bluebirdjs-cancellation](
http://bluebirdjs.com/docs/api/cancellation.html). There is assumed that
 cancellation action cause that "only active finally blocks (finally
callbacks) are executed" and then cancellation completes (there are no
chance to "override" cancellation propagation from finally callbacks in
that api) while in "real code" it is possible (and in generators to ...).

By the way in flavor of ``Promise.resolve`` and ``Promise.reject`` I would
rather "rename" ``Q.deferred`` into ``Promise.never``, in fact it would be
almost the same - factory of some promises that never completes it self by
its own but rather wait until someone pushes it from outside by the means
of abnormal ``.return`` or ``.throw``. Looks may be little bit strange, but
describes the thing nicely :)

Actually initial discussion which "inspires" me on this thoughts was in
[cancellation-tokens-related](/topic/cancel-promise-pattern-no-cancellable-promises)
topic. So here I didn't mean that it is impossible to implement that kind
of functionality on "home made" promises. I mean that it would be good to
have such functionality to "cancel"/"interrupt" execution flow of natively
generated promises, in particular to do some "cancellation" of ``async``
task represented by ``async function`` or "unsubscribe" callback in
construction ``consumer = provider.then(treatSomehow);`` and then write
``consumer.throw(new CancelationError("some reason"))`` instead of writing
 ``consumer.cancel()`` which might be "controversial" (whether we intend to
cancel provider too, in which form  we would like to do that (on which
"rail" that cancellation should be delivered? on success-rail, on
failure-rail or on some other extra-toxic cancellation-rail)). Ofcourse it
can be some very raw tools to do cancellation, but if they were present,
any "home made cancellation" would be much more doable and easy to
implement then it is now.

Regarding ``finally``/``return`` relationship I didn't mean that it is some
special feature of generators, instead, ofcourse I first of all check it on
regular functions (not only on js but in java too), and for me it was more
remarkable that ``return`` can be "replaced"  with ``break`` or
``continue`` by the means of ``finally`` block which is more interesting
case then replacing ``return`` with ``trow`` or vise versa (which ofcourse
also may lead to rather "strange" behavior and rear developer can guess
that and/or imagine that strange situation before someone else told him
about it). So putting that example with implicit ``return`` <-->
``continue`` replacement I didn't mean to show some "extra" behavior of
``generator.return()`` I only would like to highlight that ``function*``
generators implementation of ``.return`` is QUIT VALID and really simulates
``return`` behavior in place of ``yield`` instruction (without omitting any
strange "outcome" on execution flow which ``finally`` block may produce).
And it is actually one of key differences with how bluebirdjs cancleation works
as follows from [bluebirdjs-cancellation](
http://bluebirdjs.com/docs/api/cancellation.html). There is assumed that
 cancellation action cause that "only active finally blocks (finally
callbacks) are executed" and then cancellation completes (there are no
chance to "override" cancellation propagation from finally callbacks in
that api) while in "real code" it is possible (and in generators to ...).

By the way in flavor of ``Promise.resolve`` and ``Promise.reject`` I would
rather "rename" ``Q.deferred`` into ``Promise.never``, in fact it would be
almost the same - factory of some promises that never completes it self by
its own but rather wait until someone pushes it from outside by the means
of abnormal ``.return`` or ``.throw``. Looks may be little bit strange, but
describes the thing nicely :)