-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Fixes type params for OptionT.getOrElse(F) #2119
Conversation
Adds a type parameter to getOrElse and getOrElseF to conform to Option.getOrElse, which allows it to be called without needing a type hint: OptionT(Future { Option(Right(1)) }).getOrElse(Left("error")) Instead of: OptionT(Future { Option(Right(1): Either[String, Int]) }).getOrElse(Left("error"))
Codecov Report
@@ Coverage Diff @@
## master #2119 +/- ##
==========================================
+ Coverage 94.63% 94.67% +0.04%
==========================================
Files 325 328 +3
Lines 5514 5538 +24
Branches 221 199 -22
==========================================
+ Hits 5218 5243 +25
+ Misses 296 295 -1
Continue to review full report at Codecov.
|
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 @fcanedo!
There is a downside to this, which is that if you pass in a value of the wrong type you'll get back something not very useful like OptionT[Future, Any]
instead of a compile error.
However, this lines up with the getOrElse
definitions on Validated
, EitherT
, and as you mentioned, Option
. 👍 for consistency.
It might be nice to add a test for this, since it's functionality that we expect to work. |
Thanks! A doctest would be nice. |
I added some unit tests, but what’s a “doctest”? |
Doctest is really cool! You write code and expected result in Scaladoc, and it runs as a test. You can find plenty of examples here |
I can’t reproduce the errors that CI finds locally; any tips? |
It only happens on scala 2.10 and 2.11. In sbt you can type |
@kailuowang, your fix seems to solve the problem. Also, I confirmed that the tests fail to compile if I revert the fix. I think this is done. What needs to happen to get this merged? |
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 @fcanedo!
Adds a type parameter to
getOrElse
andgetOrElseF
to conform toOption.getOrElse
, which allows it to be called without needing a typehint:
Instead of: