Make DeserializationStrategy covariant at declaration-site #1897
Conversation
|
Hi! I'm terribly sorry this PR was stale for this long; it completely fell out of my sight :( I've dug through our initial design notes and haven't found any mentions regarding Given that the next release is likely going to be 1.5.0, now seems to be an excellent time to introduce this change. Can you please rebase your PR on the latest |
The type parameter T of DeserializationStrategy only appears in an out position, namely as the return type of deserialize(). It can therefore be annotated with out to increase API flexibility compared to DeserializationStrategy being invariant. E.g. a function taking DeserializationStrategy<Number> will now also accept an object of type DeserializationStrategy<Int>. This also results in DeserializationStrategy being more similar to the symmetric SerializationStrategy interface which is already contravariant at declaration-site (interface SerializationStrategy<in T>), SerializationStrategy is a consumer, DeserializationStrategy a producer. This change is * binary backwards compatible: generics are erased at runtime * source backwards compatible: previously specified out projections (use-site covariance) will only report a warning about a redundant projection
lukellmann
force-pushed
the
covariant-deserialization-strategy
branch
from
038baec to
a887620
Compare
No problem :)
Rebase is done 👍 Edit: I forgot to write this, but build is also passing locally |
sandwwraith
left a comment
sandwwraith
left a comment
There was a problem hiding this comment.
Given that the change is relatively small, I don't have any objections. Thank you!
The type parameter T of DeserializationStrategy only appears in an out position, namely as the return type of deserialize(). It can therefore be annotated with `out` to increase API flexibility compared to DeserializationStrategy being invariant. E.g. a function taking DeserializationStrategy<Number> will now also accept an object of type DeserializationStrategy<Int>. This also results in DeserializationStrategy being more similar to the symmetric SerializationStrategy interface which is already contravariant at declaration-site (interface SerializationStrategy<in T>): SerializationStrategy is a consumer, and DeserializationStrategy is a producer. This change is * binary backward compatible: generics are erased at runtime * source backward compatible: previously specified out projections (use-site covariance) will only report a warning about a redundant projection
2 participants
The type parameter
TofDeserializationStrategyonly appears in anoutposition, namely as the return type ofdeserialize().It can therefore be annotated with
outto increase API flexibility compared toDeserializationStrategybeing invariant.E.g. a function taking
DeserializationStrategy<Number>would now also accept an object of typeDeserializationStrategy<Int>.This would also result in
DeserializationStrategybeing more similar to the symmetricSerializationStrategyinterface which is already contravariant at declaration-site (interface SerializationStrategy<in T>),SerializationStrategyis a consumer,DeserializationStrategya producer.This change is
outprojections (use-site covariance) will only report a warning about a redundant projectionPlease tell me when there is a reason why this shouldn't be changed or wasn't changed before, maybe I'm missing something.