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
Covary F
in Message types.
#3107
Conversation
I thought we had this already. I prefer this to the allocating version.
To gain confidence, we could try this in a spec with a pair of effects that work, and using illTyped
, one that doesn't.
Out of curiosity, do you need this for rho, or other reasons? |
I'll write up some spec's later, wanted to get buy in before putting in the effort. I didn't need it for Rho. |
Good call, @hamnis. It would thread through |
Rather than adding a sealed trait Message[+F[_]] |
Maybe. It would probably want to start in |
Sure. Do you mind keeping this PR on hold for a little while, until I have tried those changes? |
We're already in an RC cycle, with hopes of the release next week that many people have been awaiting for too long. My inclination is to proceed with @zarthross' approach in 0.21, and consider the covariance in the next release. |
Per feedback, I've added |
Nice work. I'll open a separate ticket so we don't lose @diesalbla's idea for the future, but I think this solves the problem now.
The test failures are unrelated. Two of the newer ones are acting flaky on us.
Adding a
covary
function toMessage
and its subtypes that matches theStream.covary
function.It's implemented as a type cast to avoid the costs of creating a new
Request
object for something that should be safe to do as a cast.Alternative implementation without a type cast, (but including an extra allocation of
Request
is here