About underscores in type arguments / partial type arguments

[Brian Goetz]

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.)

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 <forax at univ-mlv.fr> wrote:
>
>
>
>     ------------------------------------------------------------------------
>
>         *From: *"Tesla Ice Zhang" <ice1000kotlin at foxmail.com>
>         *To: *"amber-dev" <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
>
>         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
>
>
>         Best regards,
>         Tesla
>
>
>     regards,
>     Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230122/39ebf77b/attachment-0001.htm>