About underscores in type arguments / partial type arguments

forax at univ-mlv.fr forax at univ-mlv.fr
Sun Jan 22 15:21:10 UTC 2023


> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Red IO" <redio.development at gmail.com>, "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Tesla Ice Zhang" <ice1000kotlin at foxmail.com>, "amber-dev"
> <amber-dev at openjdk.org>
> Sent: Sunday, January 22, 2023 3:00:05 PM
> Subject: Re: About underscores in type arguments / partial type arguments

> The main choices you get in selecting a type inference scheme are (a) where to
> gather constraints and (b) when to solve them. Java chooses, sensible, to do
> its solving at the level of a single statement or expression, rather than the
> entire body of a method. While this might seem like "throwing away useful
> information", it enables more local reasoning; you don't have to worry about
> implementation details hundreds of lines away affecting the result of
> inference. I think its safe to say we made our choice a long time ago and are
> still happy with it.

> (BTW, Rust didn't invent global type inference either; see [
> https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system |
> https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system ] .)

I don't know Rust well, i've just played with it but as i understand it does not use global inference but more a kind of delayed inference, there is a type (say Unknown) which say that there is no constraint and later when constraints are found, Unknown is replaced by type inferred. I've seen something similar in Haxe (which predates Rust). 
It works well in Rust because Rust uses a type flow algorithm where the type of a variable change depending on the control flow (like Kotlin or TypeScript). 

regards, 
Rémi 

> On 1/21/2023 5:40 AM, Red IO wrote:

>> I'm not sure how well this would fit in Java, but rust has long reaching
>> backwards inference. Example:
>> var hashmap = new Hashmap<>();
>> hashmap.add(5, "Hello");
>> Where the first use of a type variable here int, String infers the type of the
>> hashmap.
>> This would allow patterns to avoid specifying the type variables they want by
>> inferring them by usage inside the pattern.

>> Great regards
>> RedIODev

>> On Sat, Jan 21, 2023, 08:01 Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] > wrote:

>>>> From: "Tesla Ice Zhang" < [ mailto:ice1000kotlin at foxmail.com |
>>>> ice1000kotlin at foxmail.com ] >
>>>> To: "amber-dev" < [ mailto:amber-dev at openjdk.org | amber-dev at openjdk.org ] >
>>>> Sent: Saturday, January 21, 2023 3:23:39 AM
>>>> Subject: About underscores in type arguments / partial type arguments

>>>> Hi all,
>>>> Is there any discussion related to partially specified type arguments (which are
>>>> left for inference)? I just saw that Kotlin 1.7 added support for that. It
>>>> would be nice if Java can have that too: [
>>>> https://kotlinlang.org/docs/whatsnew17.html#underscore-operator-for-type-arguments
>>>> |
>>>> https://kotlinlang.org/docs/whatsnew17.html#underscore-operator-for-type-arguments
>>>> ]

>>>> The demonstration of the feature in the above document is also applicable to
>>>> Java.

>>> Yes, this has been discussed several times not only in the context of patterns
>>> but also in the context of inference in general.

>>> For patterns, currently you have to repeat all type arguments

>>> Map<String, Integer> map = ...
>>> switch(map) {
>>> case HashMap<String, Integer> m -> ...
>>> ...

>>> we talk about simplify it using
>>> case HashMap<> m -> ...

>>> but this means also supporting
>>> if (map instanceof HashMap<> m) { ...

>>> and maybe also supporting
>>> if (map instanceof HashMap) {
>>> var m = (HashMap<>) map;
>>> ...
>>> }

>>> One issue is that the inference rules are not the same as the usual inference
>>> rules, because you want to be able to infer something like HashMap<?,?> while
>>> you do not want to infer new HashMap<?,?>() in the general context.

>>> Currently, we are trying to see if we can avoid to specify the angle brackets
>>> all together, so more "case HashMap" than "case HashMap<>".
>>> see [
>>> https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221115/specs/patterns-switch-record-patterns-jls.html#jls-18.5.5
>>> |
>>> https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221115/specs/patterns-switch-record-patterns-jls.html#jls-18.5.5
>>> ]

>>>> Best regards,
>>>> Tesla

>>> regards,
>>> Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230122/e2a8f319/attachment.htm>


More information about the amber-dev mailing list