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

improve liftTo/rethrowT/raiseOrPure syntax to be more flexible #2984

Merged
merged 2 commits into from
Aug 16, 2019
Merged

improve liftTo/rethrowT/raiseOrPure syntax to be more flexible #2984

merged 2 commits into from
Aug 16, 2019

Conversation

bpholt
Copy link
Member

@bpholt bpholt commented Aug 12, 2019

This takes the changes in #2880 and extends them to a few more methods with similar usage.

kailuowang
kailuowang previously approved these changes Aug 12, 2019
@kailuowang
Copy link
Contributor

Thanks!

@codecov-io
Copy link

codecov-io commented Aug 12, 2019

Codecov Report

Merging #2984 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #2984   +/-   ##
=======================================
  Coverage   93.83%   93.83%           
=======================================
  Files         369      369           
  Lines        7072     7072           
  Branches      195      195           
=======================================
  Hits         6636     6636           
  Misses        436      436
Impacted Files Coverage Δ
core/src/main/scala/cats/syntax/validated.scala 80% <ø> (ø) ⬆️
core/src/main/scala/cats/data/EitherT.scala 97.93% <ø> (ø) ⬆️
core/src/main/scala/cats/syntax/either.scala 86.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 0de7503...fd8a7e8. Read the comment docs.

def raiseOrPure[F[_]](implicit ev: ApplicativeError[F, A]): F[B] =
ev.fromEither(eab)
@deprecated("use liftTo instead", "2.0.0")
def raiseOrPure[F[_]](implicit F: ApplicativeError[F, _ >: A]): F[B] =
Copy link
Member

Choose a reason for hiding this comment

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

If we're deprecating this, why change the signature? Should we just leave this as is?

Copy link
Member Author

Choose a reason for hiding this comment

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

That's a good question… as far as I could tell, there was no downside to changing it, so I thought I might as well, in case we end up not deprecating it or it comes in handy for someone. 🤷‍♂

As long as the deprecated version is there too, it might also improve discoverability? I stumbled across liftTo for this purpose because I asked about raiseOrPure in Gitter and @kubukoz said it sounded like liftTo with worse types. Maybe better types for raiseOrPure makes it easier to find, and then the deprecation warning points you to the canonically-named method? Idk.

Copy link
Contributor

Choose a reason for hiding this comment

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

The downside is that there is a small chance it breaks source for some users. If we deprecate it , there is really no reason to improve as it only encourage users to use it right?

Copy link
Member Author

Choose a reason for hiding this comment

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

It makes sense to be conservative. I reverted the signature change and left the deprecation in place.

I'm a little curious when this change could break source, though… do you happen to know any examples?

Copy link
Contributor

@kailuowang kailuowang Aug 15, 2019

Choose a reason for hiding this comment

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

@bpholt it's probably going to be some extreme edge cases but imagine where there are two ApplicativeError instances for F in scope, one of them is ApplicativeError[F, A]
, the other is ApplicativeError[F, AA] where A is a subtype of AA

Copy link
Contributor

Choose a reason for hiding this comment

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

Again it's not really expected to break some users, that's why we are totally okay with the other changes.

LukaJCB
LukaJCB previously approved these changes Aug 15, 2019
kailuowang
kailuowang previously approved these changes Aug 15, 2019
@@ -350,6 +350,12 @@ class EitherSuite extends CatsSuite {
}
}

test("raiseOrPure syntax works with specialized errors") {
Copy link
Contributor

Choose a reason for hiding this comment

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

no longer valid

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, good catch

@bpholt bpholt dismissed stale reviews from kailuowang and LukaJCB via fd8a7e8 August 15, 2019 20:44
@kailuowang kailuowang merged commit 481b5ff into typelevel:master Aug 16, 2019
@bpholt bpholt deleted the widening-rethrow branch August 16, 2019 16:46
@travisbrown travisbrown added this to the 2.0-RC2 milestone Aug 26, 2019
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.

5 participants