About underscores in type arguments / partial type arguments

[Red IO]

Yes as my example showed and tesla correctly added rust uses type inference
on scope level (not global). But rusts variables never change type if not
casted (safe or unsafe) the type and inference system is in fact very
strict amd completely different from something like typescript.

I agree with Brian that using "backwards inference" would be confusing and
or would require every inference to use it what would be confusing too.

But as I was reading the examples from remi again and doing some testing of
my own there isn't really a need for this in this idea.
Since:

Object o = new ArrayList<String>();
if (o instanceof ArrayList<Foo> f) {
...
}
Where Foo is any type including String.
Is always a compilation error since it cannot be solved by static analysis.
The only pattern where:
if (foo instanceof Bar<Baz> b) {
...
}
Is valid is when foo's generic parameters match these from Bar (or include
them) and therefore static analysis can typecheck the generic parameters.
(not possible at runtime due to type erasure).
Therefore we can assume that we know the generic parameters at time of
instanceof / case and can safely infer them using <> when we do not want to
change the bound of the generic parameters like <? extends Baz>.

I think adding inference to this pattern would be very beneficial to
readability and writeability.

Great regards
RedIODev


On Sun, Jan 22, 2023, 16:21 <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *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.)
>
>
> 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 <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/743c0062/attachment-0001.htm>