Make Functions.constant covariant in argument type.
See original GitHub issuePresently, a constant function is provided in the Functions
class with a type signature as follows
public static <E> Function<Object, E> constant(@Nullable E value)
Personally, I think that a type signature as follows would be superior
public static <Q, E> Function<Q, E> constant(@Nullable E value)
the reason being that while functions in the “mathematical” sense are co-variant with regard to their argument types, generics in java are not (for well-known reasons).
It’s probably not trivial to introduce such a change without triggering a compilation error here or there. Still I think it might be worth considering.
Issue Analytics
- State:
- Created 9 years ago
- Reactions:1
- Comments:6 (3 by maintainers)
Top Results From Across the Web
TypeScript: subtyping and covariant argument types
1 Answer 1 ... As per krontogiannis' comment above, when comparing function types, one can be a subtype of the other either because...
Read more >typing — Support for type hints — Python 3.11.1 documentation
In the function greeting , the argument name is expected to be of type str and the return type str . Subtypes are...
Read more >allow const modifier in function parameter and return type for ...
I have an extension function on List<Widget> which inserts SizedBox between every child to set spacing, instead of manually putting SizedBox ...
Read more >Covariance and contravariance in C++ – Arthur O'Dwyer
Today I'd like to try to explain covariance and contravariance, and the many places we see that notion pop up in C++.
Read more >Fixing common type problems - Dart
This means you can't write code where a variable's value differs from its ... error - The argument type 'bool Function(String)' can't be...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
There are no doubt many plausible workarounds (as it were, I am quite content with mine). It is also a very minor issue. I simply felt it noteworthy that a workaround would seem to be required in the first place. Please do feel free to close it if it isn’t worth your time.
As “solutions” go though, my proposal would be to make
ConstantFunction
generic in the parameter type as follows:and either change or provide an alternative to
constant(T val)
:Though again, I do agree that this is generics cosmetics, and perhaps not worth the possible API change/extension.
Generics aren’t, but specific uses of generic types that happen to be covariant should be – e.g. most places that accept a Function<F, T> should accept a Function<? super F, ? extends E> where appropriate.
Is there a place you cannot make this change to the user of the Function?