Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coroutines should resolve with the generator return value #42

Closed
felixfbecker opened this issue Oct 11, 2016 · 8 comments
Closed

Coroutines should resolve with the generator return value #42

felixfbecker opened this issue Oct 11, 2016 · 8 comments

Comments

@felixfbecker
Copy link
Contributor

felixfbecker commented Oct 11, 2016

PHP 7 has Generator::getReturn() to get the return value of a generator. That means code like this is possible:

coroutine(function () {
  $x = yield someAsync();
  if ($x->whatever) {
    return 'thisvalue';
  }
  $y = yield someOtherAsync();
  if ($y->whatever) {
    return 'thatvalue';
  }
  return yield $y->whatelse();

But currently coroutines will always use the last yield value, which makes control flow like above weird.

@evert
Copy link
Member

evert commented Oct 11, 2016

This is a great idea, thanks!

@felixfbecker
Copy link
Contributor Author

felixfbecker commented Oct 11, 2016

References that behave the same:
https://tc39.github.io/ecmascript-asyncawait/
https://www.npmjs.com/package/co
http://bluebirdjs.com/docs/api/promise.coroutine.html

This would simplify my code a lot, currently I have to yield another time before calling return to abort early.

@evert
Copy link
Member

evert commented Oct 11, 2016

Do you think this is possible in a backwards compatible way? Or does this mean we need to do a 5.0.0 release?

@felixfbecker
Copy link
Contributor Author

I think it's a breaking change because it changes the semantics. Any code that does

if ($whatever) {
  yield whatever();
  return;
}

will get null as resolve value (and it should be that way). Previously it would be the return value of whatever().

I think it's worth it though. Nobody is forced to update after all, but those who do and new projects benefit from a lot less boilerplate, cleaner semantics and shared behavior with how other implementations work. #43 is also kind of a breaking change in case you relied on the error being thrown.

@evert
Copy link
Member

evert commented Oct 11, 2016

Well I fully agree that this should happen. So lets make this a priority and cut a v5.0. Sucks a bit to have a major version just after the last, but worth it!

@staabm
Copy link
Member

staabm commented Oct 12, 2016

agree, just do another major release. no worries.

@felixfbecker
Copy link
Contributor Author

ETA for 5.0?

@evert
Copy link
Member

evert commented Oct 23, 2016

Just released it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants