-
Notifications
You must be signed in to change notification settings - Fork 246
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
Java: please emit covariant Map types #1517
Labels
effort/small
Small work item – less than a day of effort
feature-request
A feature should be added or improved.
language/dotnet
Related to .NET bindings (C#, F#, ...)
language/java
Related to Java bindings
p2
Comments
I like this idea a lot! I don't reckon C# needs something similar... But we should add a compliance test to confirm that. |
RomainMuller
added a commit
that referenced
this issue
May 12, 2020
Using covariant expressions instead of just the type name enables a better experience when using libraries such as Guava to build up collections (`List` or `Map`) to use with the libraries. In particular, collections of `any` are particularly annoying to use without covariant typing because they'd force the user to manually specify generic parameters in their code that add nothing to the safety of the program. Fixes #1517
mergify bot
pushed a commit
that referenced
this issue
May 13, 2020
Using covariant expressions instead of just the type name enables a better experience when using libraries such as Guava to build up collections (`List` or `Map`) to use with the libraries. In particular, collections of `any` are particularly annoying to use without covariant typing because they'd force the user to manually specify generic parameters in their code that add nothing to the safety of the program. Fixes #1517
Opening this cause we had to temporary revert the change |
RomainMuller
added a commit
that referenced
this issue
Aug 13, 2020
Using covariant expressions instead of just the type name enables a better experience when using libraries such as Guava to build up collections (`List` or `Map`) to use with the libraries. In particular, collections of `any` are particularly annoying to use without covariant typing because they'd force the user to manually specify generic parameters in their code that add nothing to the safety of the program. Fixes #1517
RomainMuller
added a commit
that referenced
this issue
Aug 21, 2020
Using covariant expressions instead of just the type name enables a better experience when using libraries such as Guava to build up collections (`List` or `Map`) to use with the libraries. In particular, collections of `any` are particularly annoying to use without covariant typing because they'd force the user to manually specify generic parameters in their code that add nothing to the safety of the program. Fixes #1517
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
effort/small
Small work item – less than a day of effort
feature-request
A feature should be added or improved.
language/dotnet
Related to .NET bindings (C#, F#, ...)
language/java
Related to Java bindings
p2
🚀 Feature Request
Affected Languages
Java
C#
,F#
, ...) (maybe! I don't know)Right now, a
{[key: K]: V}
(orRecord<K, V>
which I prefer writing because all those curlies make me dizzy :) ), renders to the following type in Java:Example:
I'd like to use this in the IAM library in
addCondition()
, where the user needs to actually pass aRecord<string, string | string[]>
, but since we don't do unions we take the common supertype, which isany
.The problem is, most people are going to want to use an
ImmutableMap<>
to pass as an argument. That's fine, but the effective type of that map in 9 times out of 10 is going to be:And it so happens that you cannot assign a
Map<String, String>
to aMap<String, Object>
, as Java doesn't know about the subtyping relationship you intend (and prefers not to guess).Proof:
https://repl.it/repls/TalkativeUnrulyTheories
Proposed solution
The actual type we should be emitting in Java, to mirror the subtyping relationship in TypeScript, is the following:
(In fact it should actually be
Map<? extends String, ? extends Object>
, but since we never have anything other than aString
in the first position (because JavaScript), we can simplify a little...)And the same for
List
.You would need to investigate yourself whether we need to explicitly annotate C# as well, or not.
The text was updated successfully, but these errors were encountered: