-
-
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
Explicit functor variance #1097
Conversation
Current coverage is 88.57%
@@ master #1097 diff @@
==========================================
Files 226 226
Lines 2917 2931 +14
Methods 2867 2879 +12
Messages 0 0
Branches 48 49 +1
==========================================
+ Hits 2594 2596 +2
- Misses 323 335 +12
Partials 0 0
|
I think the only useful tests for widen and narrow are going to be fairly low-level. I'll add some for codecov. |
You could probably add an sbt-doctest to solve the codecov difference ? |
Can you point to a discussion about the pros and cons of this approach versus using a variance annotation? |
@@ -18,6 +18,12 @@ import simulacrum.typeclass | |||
|
|||
// derived methods | |||
|
|||
/* |
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.
Could you please add another *
so that this becomes a ScalaDoc comment?
@edmundnoble thanks! Looking good so far. I agree with @peterneyens that some doctest examples would be good and will help out the code coverage. Another thing that you could do is add some property-tests that |
I agree with @ceedubs specific comment syntax remarks, but other than that +1 from me. Tests and/or examples would be nice too if you felt like doing them. |
@julienrf That's proving surprisingly hard to find. I can find a good argument against using a contravariance annotation on Contravariant: https://issues.scala-lang.org/browse/SI-2509. |
9ceec4d
to
980ba09
Compare
980ba09
to
4c5db8b
Compare
I've made the comments into scaladoc comments, and added some doctest stuff and tests. |
👍 thanks! @julienrf I don't know of a discussion about this approach vs adding a variance annotation to point to. I can add some notes here though. If you were to write an invariant The previous paragraph referred to putting the variance annotation on the data structure. If you were to put the variance annotation on the type class instances (like |
Looks good to me. 👍 |
This uses casts to implement
Functor.widen
andContravariant.narrow
to take advantage of the natural variance of Functors with respect to subtyping.Functor.widen
in Scalaz works similarly (though it uses Liskov and@uncheckedVariance
in its implementation, it has the same underlying optimization).