Skip to content
New issue

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

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

Already on GitHub? # to your account

Implement OptionT#foreachF #4015

Merged
merged 3 commits into from
Oct 20, 2021

Conversation

armanbilge
Copy link
Member

No description provided.

satorg
satorg previously approved these changes Oct 12, 2021
Copy link
Contributor

@satorg satorg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good and reasonable to me, thanks.

Would it be too much trouble to add a sort of "stabilizing" test case to OptionTSutie please? I don't really think it is absolutely necessary here, but I believe it is always nice to have.

@satorg
Copy link
Contributor

satorg commented Oct 12, 2021

Just an idea: would you consider by chance to add a similar foreachF to EitherT for consistency with Either and Option (since Either has a regular foreach as well as Option)?

@armanbilge
Copy link
Member Author

Thanks, yes I can add a test, sorry for being lazy :) what do you mean by "stabilizing"? I was thinking a prop testing its identity with fold.

Regarding EitherT, I can see the argument for consistency but IMHO foreach on Either seems like an anti-pattern that I personally would never use (since it silently loses/ignores the left). The whole point of Either is to preserve both channels, if someone really wants to do this I think you should just convert to Option first (this will make it very clear you are losing the error channel) and then do foreach. But just my opinion :)

@satorg
Copy link
Contributor

satorg commented Oct 12, 2021

what do you mean by "stabilizing"?

I just meant although the implementation seems straightforward, but it might be useful to "pin" it to make sure it won't be accidentally broken in the future. The Prop based test you mentioned would be just great.

Regarding EitherT, I can see the argument for consistency but IMHO foreach on Either seems like an anti-pattern that I personally would never use (since it silently loses/ignores the left). The whole point of Either is to preserve both channels, if someone really wants to do this I think you should just convert to Option first (this will make it very clear you are losing the error channel) and then do foreach. But just my opinion :)

Agree, that makes sense to me.

satorg
satorg previously approved these changes Oct 12, 2021
* Transform this `OptionT[F, A]` into a `F[Unit]`.
* This is identical to `foldF(F.unit)(f)`.
*/
def foreachF[B](f: A => F[Unit])(implicit F: Monad[F]): F[Unit] =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

side note, this foldMap where B =:= F[Unit]. But I think we can't implicitly resolve Monoid[F[A]] given F[_]: Applicative (since I don't think that resolves without additional imports).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting note!

* Transform this `OptionT[F, A]` into a `F[Unit]`.
* This is identical to `foldF(F.unit)(f)`.
*/
def foreachF[B](f: A => F[Unit])(implicit F: Monad[F]): F[Unit] =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

B type parameter is unused. Can we remove it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, right. Thanks.

Suggested change
def foreachF[B](f: A => F[Unit])(implicit F: Monad[F]): F[Unit] =
def foreachF(f: A => F[Unit])(implicit F: Monad[F]): F[Unit] =

Co-authored-by: P. Oscar Boykin <johnynek@users.noreply.github.com>
@johnynek johnynek merged commit 899e520 into typelevel:main Oct 20, 2021
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants