<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto">Since:</div><div dir="auto"><br></div><div dir="auto">Object o = new ArrayList<String>();</div><div dir="auto">if (o instanceof ArrayList<Foo> f) {</div><div dir="auto">... </div><div dir="auto">}</div><div dir="auto">Where Foo is any type including String. </div><div dir="auto">Is always a compilation error since it cannot be solved by static analysis.</div><div dir="auto">The only pattern where:</div><div dir="auto">if (foo instanceof Bar<Baz> b) {</div><div dir="auto">... </div><div dir="auto">} </div><div dir="auto">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). </div><div dir="auto">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>. </div><div dir="auto"><br></div><div dir="auto">I think adding inference to this pattern would be very beneficial to readability and writeability. </div><div dir="auto"><br></div><div dir="auto">Great regards </div><div dir="auto">RedIODev </div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 22, 2023, 16:21 <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:#000000"><div><br></div><div><br></div><hr id="m_-7577661188900435318zwchr"><div><blockquote style="border-left:2px solid #1010ff;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Brian Goetz" <<a href="mailto:brian.goetz@oracle.com" target="_blank" rel="noreferrer">brian.goetz@oracle.com</a>><br><b>To: </b>"Red IO" <<a href="mailto:redio.development@gmail.com" target="_blank" rel="noreferrer">redio.development@gmail.com</a>>, "Remi Forax" <<a href="mailto:forax@univ-mlv.fr" target="_blank" rel="noreferrer">forax@univ-mlv.fr</a>><br><b>Cc: </b>"Tesla Ice Zhang" <<a href="mailto:ice1000kotlin@foxmail.com" target="_blank" rel="noreferrer">ice1000kotlin@foxmail.com</a>>, "amber-dev" <<a href="mailto:amber-dev@openjdk.org" target="_blank" rel="noreferrer">amber-dev@openjdk.org</a>><br><b>Sent: </b>Sunday, January 22, 2023 3:00:05 PM<br><b>Subject: </b>Re: About underscores in type arguments / partial type arguments<br></blockquote></div><div><blockquote style="border-left:2px solid #1010ff;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><font size="4"><font face="monospace">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.<br><br>
(BTW, Rust didn't invent global type inference either; see
<a href="https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system" target="_blank" rel="noreferrer">https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system</a>.)<br></font></font></blockquote><div><br></div><div>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).<br></div><div>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).<br></div><div><br></div><div>regards,<br></div><div>Rémi<br></div><div><br></div><blockquote style="border-left:2px solid #1010ff;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt">
<div>On 1/21/2023 5:40 AM, Red IO wrote:<br>
</div>
<blockquote>
<div dir="auto">I'm not sure how well this would fit in Java, but
rust has long reaching backwards inference. Example:
<div dir="auto">var hashmap = new Hashmap<>();</div>
<div dir="auto">hashmap.add(5, "Hello");</div>
<div dir="auto">Where the first use of a type variable here int,
String infers the type of the hashmap.</div>
<div dir="auto">This would allow patterns to avoid specifying
the type variables they want by inferring them by usage inside
the pattern.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Great regards </div>
<div dir="auto">RedIODev </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Jan 21, 2023, 08:01
Remi Forax <<a href="mailto:forax@univ-mlv.fr" target="_blank" rel="noreferrer">forax@univ-mlv.fr</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:#000000">
<div><br>
</div>
<div><br>
</div>
<hr id="m_-7577661188900435318m_-6008077281224607691zwchr">
<div>
<blockquote style="border-left:2px solid #1010ff;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From:
</b>"Tesla Ice Zhang" <<a href="mailto:ice1000kotlin@foxmail.com" rel="noreferrer noreferrer" target="_blank">ice1000kotlin@foxmail.com</a>><br>
<b>To: </b>"amber-dev" <<a href="mailto:amber-dev@openjdk.org" rel="noreferrer noreferrer" target="_blank">amber-dev@openjdk.org</a>><br>
<b>Sent: </b>Saturday, January 21, 2023 3:23:39 AM<br>
<b>Subject: </b>About underscores in type arguments /
partial type arguments<br>
</blockquote>
</div>
<div>
<blockquote style="border-left:2px solid #1010ff;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt">Hi
all,<br>
<div>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: <a href="https://kotlinlang.org/docs/whatsnew17.html#underscore-operator-for-type-arguments" rel="noreferrer noreferrer" target="_blank">https://kotlinlang.org/docs/whatsnew17.html#underscore-operator-for-type-arguments</a><br></div>
<br>
<div>The demonstration of the feature in the above
document is also applicable to Java.</div>
</blockquote>
<div><br>
</div>
<div>Yes, this has been discussed several times not only
in the context of patterns but also in the context of
inference in general.<br>
</div>
<div><br>
</div>
<div>For patterns, currently you have to repeat all type
arguments<br>
</div>
<div><br>
</div>
<div> Map<String, Integer> map = ...<br>
</div>
<div> switch(map) {<br>
</div>
<div> case HashMap<String, Integer> m -> ...<br>
</div>
<div> ...<br>
</div>
<div><br>
</div>
<div>we talk about simplify it using<br>
</div>
<div> case HashMap<> m -> ...<br>
</div>
<div> <br>
</div>
<div>but this means also supporting</div>
<div> if (map instanceof HashMap<> m) { ...<br>
</div>
<div><br>
</div>
<div>and maybe also supporting<br>
</div>
<div> if (map instanceof HashMap) {<br>
</div>
<div> var m = (HashMap<>) map;<br>
</div>
<div> ...<br>
</div>
<div> }<br>
</div>
<div> <br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Currently, we are trying to see if we can avoid to
specify the angle brackets all together, so more "case
HashMap" than "case HashMap<>".<br>
</div>
<div>see <a href="https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221115/specs/patterns-switch-record-patterns-jls.html#jls-18.5.5" rel="noreferrer noreferrer" target="_blank">https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221115/specs/patterns-switch-record-patterns-jls.html#jls-18.5.5</a><br>
</div>
<div><br>
</div>
<blockquote style="border-left:2px solid #1010ff;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><br>
<div>Best regards,</div>
<div>Tesla</div>
</blockquote>
<div><br>
</div>
<div>regards,<br>
</div>
<div>Rémi<br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br><br></blockquote></div></div></div></blockquote></div>