-
Couldn't load subscription status.
- Fork 1.4k
New operator getOrFailUnit to control side-effect of Option returning… #4163
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
Conversation
|
@adamgfraser do you know if those test that are failing, are flaky test?, I've been checking and are not related with this feature. And in local fails only some times. I think there must be some RC with the timeouts |
|
@politrons Yes they are. You want to revert the change to the other test just so we aren’t messing with unrelated things and then I will rerun the tests so we can get this merged? |
|
@adamgfraser I already revert the test. With some more context I could try to fix those flaky test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your work on this!
| /** | ||
| * @see See [[zio.ZIO.getOrFailUnit]] | ||
| */ | ||
| def getOrFailUnit[A](v: => Option[A]): IO[Unit, A] = ZIO.getOrFailUnit(v) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adamgfraser Shouldn't this be IO[None.type, A] as per more recent convention?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jdegoes The goal of this constructor was to have a variant for users who want Unit in the error channel instead of None.type. So we have ZIO.fromOption for the normal recommended usage, ZIO.getOrFailUnit for if you really want Unit in the error channel, and ZIO.getOrFail for if you want NoSuchElementException in the error channel (for example, for unifying with other errors that are a subtype of Throwable). Does that make sense?
I know with the migration of Scalaz to dev.zio the fromOption operator was refactor to allow use composition and other goodies to use Option instead the wrapped value.
Still in my team and other teams in my organization they claim they still want to have an operator to extract the value from the option once we transform into IO. And they will like to have still an operator IO[Unit, A]
That's why I bring back the feature we had in scalaz here with the tmp name fromOptionValue that return IO[Unit, A]
Again I understand the reasons why the operator was refactor, and I'm just bringing another alternative for those that dont want use the goodies of the new operator.
This MR is still work in progress, and only in case it's consider I will continue working with documentation and all the necessary stuff.
@andreamarcolin Finally I close and create a new PR take a look when you have some time.