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

Add Applicative IorT instance #2181

Closed
wants to merge 2 commits into from

Conversation

LukaJCB
Copy link
Member

@LukaJCB LukaJCB commented Mar 2, 2018

This was a missing instances cc @arosien

@codecov-io
Copy link

Codecov Report

Merging #2181 into master will increase coverage by 0.04%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2181      +/-   ##
==========================================
+ Coverage   94.71%   94.75%   +0.04%     
==========================================
  Files         329      330       +1     
  Lines        5558     5572      +14     
  Branches      215      218       +3     
==========================================
+ Hits         5264     5280      +16     
+ Misses        294      292       -2
Impacted Files Coverage Δ
core/src/main/scala/cats/data/IorT.scala 97.82% <100%> (+0.06%) ⬆️
core/src/main/scala/cats/syntax/option.scala 100% <0%> (ø) ⬆️
.../src/main/scala/cats/syntax/applicativeError.scala 100% <0%> (ø) ⬆️
core/src/main/scala/cats/syntax/TrySyntax.scala 100% <0%> (ø)
core/src/main/scala/cats/syntax/either.scala 99.16% <0%> (ø) ⬆️
core/src/main/scala/cats/ApplicativeError.scala 100% <0%> (+11.76%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 60c3546...853fb9c. Read the comment docs.

@peterneyens
Copy link
Collaborator

peterneyens commented Mar 3, 2018

EitherT and OptionT explicitly don't have this instance because it is inconsistent with the Monad instance (which is one of the reason for the toNested methods on those data types). (See #1467 for some discussion and links).

I haven't checked it for IorT, but I suspect it will have the same issue.

implicit val F = ListWrapper.applicative

checkAll("IorT[ListWrapper, String, Int]", ApplicativeTests[IorT[ListWrapper, String, ?]].applicative[Int, Int, Int])
checkAll("Applicative[IorT[List, ?, ?]]", SerializableTests.serializable(Applicative[IorT[ListWrapper, String, ?]]))
Copy link

Choose a reason for hiding this comment

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

The description says List but the code uses ListWrapper. Is this intended ?

@LukaJCB
Copy link
Member Author

LukaJCB commented Mar 5, 2018

Thanks for pointing that out @peterneyens! I wasn't aware this would lead to inconsistencies, I understand how OptionT and EitherT would differ, but I'm not 100% certain I'd be the same for IorT I'll have to investigate some more.

@arosien
Copy link

arosien commented Mar 8, 2018

@peterneyens @LukaJCB perhaps we could add some kind of scaladoc that would let the user know to call toNested to use this in an Applicative manner.

@kailuowang
Copy link
Contributor

I created #2272, shall we close this?

@LukaJCB
Copy link
Member Author

LukaJCB commented May 30, 2018

Yup :)

@LukaJCB LukaJCB closed this May 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants