News for hackers. Stuff that matters.

A comment on Understanding contravariance. Parent comment

Re:Understanding contravariance by TheCoelacanth on Friday June 22, 2018 @01:05PM (#17375569)
I disagree. The problem is with the difference between a source and a sink not being represented in the type system. With that difference represented properly, variance becomes very simple. A source is covariant, a sink is contravariant and something that is both a source and a sink is invariant. That is slightly harder for the language designer but much easier for the user.
[ Parent | on HN ]
Re:Understanding contravariance by munificent on Friday June 22, 2018 @01:24PM (#17375705)
That covers many cases, but not all. Consider:

    bool contains(other) { ... }
This looks like a sink operation — you're passing a value in, just like you do with add() — but is naturally covariant, not contravariant.
[ Parent | on HN ]
Re:Understanding contravariance by TheCoelacanth on Friday June 22, 2018 @04:07PM (#17376938)
That's a source operation. You aren't putting values into the collection, you are examining values in the collection.
[ Parent | on HN ]
Re:Understanding contravariance by munificent on Friday June 22, 2018 @04:51PM (#17377236)
Yes, except the type argument appears in parameter position, which is typically contravariant.
[ Parent | on HN ]
Re:Understanding contravariance by TheCoelacanth on Friday June 22, 2018 @09:24PM (#17378879)
Okay, but it's not. Make source vs. sink explicit and it will be obvious because the method will be defined on source and not on sink.
[ Parent | on HN ]