4 ms·
> Therefore I doubt if it is really needed Well the article seems to suggest that it absolutely is needed for function arguments.
by Sean1708 9y ago
> Therefore I doubt if it is really needed
Well the article seems to suggest that it absolutely is needed for function arguments.
- Sharlin 9y agoIt is not essential, and neither is covariance. For instance, C and C++ function types are invariant (but C++ virtual member functions are properly variant, and so is std::function). If a language does not support variance, it can always be emulated with wrapper functions. Eg. given types A :> B :> C fn foo: (B -> B) -> () fn bar: A -> C foo(b -> bar(b)) where the lambda has (inferred) type B -> B.
- techno_modus 9y agoYou are right, I probably did not express my idea clearly. What I meant is that there is only one meaningful pattern: returns are covariant and arguments are contravariant. If it is so (and the articles seems to confirm this) then why do we need special annotations? The system could itself assume that any argument (by default) is contravariant and any return (by default) is covariant. Does it make sense?
- lmm 9y ago> The system could itself assume that any argument (by default) is contravariant and any return (by default) is covariant. I guess languages could infer variance for generic parameters on methods/functions, and perhaps should - it would align with how type systems generally work. But that's a small part of the use case - variance mainly matters when you have generic values. If we have a Frobnicator[A, B] it would be very difficult for the language to infer whether variance for frobnicator values should run like for A => B, like for B => A, or some other way.
- renox 9y agoExcept that in many languages you have also input/ouput parameters that should be invariant, I agree.