<div dir="ltr"><div dir="ltr">On Wed, Dec 13, 2023 at 3:07 PM <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><br><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
captured fields in lambda are like strict but captured fields is inner classes are like normal fields.<br></blockquote><br><div>I was curious why this would be true and it appears it's not true, at least from this test:</div></div></div></blockquote><div><br></div><div>Yes, but you can still change the value of the field by reflection, unlike with the fields of a lambda proxy, so the field containing the captured value is not strict.<br></div></div></div></div></blockquote><div><br></div><div>Thanks for the clarification, I missed that piece of it.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><div></div><div><br></div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div class="gmail_quote"><div>My opinion is also "no" on this question... but because it would add another logical fork in developers' minds for too little benefit. It's easy enough to just put it in there explicitly.</div></div></div></blockquote><div><br></div><div>What we are trying to do here, is to follow Dan's idea that there is no need for an additional keyword and that the compiler can infer the strictness by itself.<br></div><div>As you said, the problem of that idea is that the developer is not really in control, subtle changes like the initializer depending on 'this' make the final field strict or not.<br></div></div></div></div></blockquote><br></div><div class="gmail_quote">So it would boil down to the difference between:</div><div class="gmail_quote"><br></div><div class="gmail_quote"><span style="font-family:monospace"> private final int x; // not strict<br></span></div><div class="gmail_quote"><span style="font-family:monospace"> Foo(int x) {<br></span></div><div class="gmail_quote"><span style="font-family:monospace"> // implicit super()</span><span style="font-family:monospace"> goes here</span></div><div class="gmail_quote"><span style="font-family:monospace"> this.x = x;</span></div><div class="gmail_quote"><span style="font-family:monospace"> }</span></div><div class="gmail_quote"><br></div><div class="gmail_quote">vs.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><div class="gmail_quote"><span style="font-family:monospace"> private final int x; // implicitly strict<br></span></div><div class="gmail_quote"><span style="font-family:monospace"> Foo(int x) {<br></span></div><span style="font-family:monospace"> this.x = x;</span><div class="gmail_quote"><div class="gmail_quote"><span style="font-family:monospace"> // implicit super() goes here<br></span></div><span style="font-family:monospace"> }</span></div><div class="gmail_quote"><br></div><div class="gmail_quote">which only differ in behavior in the introspection and serialization domains.<br></div></div><div class="gmail_quote"><div class="gmail_quote"><div><br></div>Thanks - now I get it.</div><div class="gmail_quote"><br></div></div>-Archie<br clear="all"><div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div></div>