<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">On 21 Jul 2022, at 6:54, <a href="mailto:forax@univ-mlv.fr" style="color: #3983C4;">forax@univ-mlv.fr</a> wrote:</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">…</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #BBBBBB; color: #BBBBBB;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #BBBBBB; color: #BBBBBB;"><p dir="auto">I've no idea about the performance of such kind of implementations, but >>> using</p>
</blockquote><p dir="auto">T.flat give better control on what is flattenable or not in the implementation.</p>
</blockquote><p dir="auto">If we choose, we can code this trick in the design of record as well.</p>
</blockquote><p dir="auto">You mean in the design of array ? I don't think it's wise given that the shape of the array change, but perhaps GCs can be modified to add a relocate and unflat operation to array.</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">No, I mean in the design of ArrayList (or similar generics) in the way you sketch. If we choose we can create shape-shifting List/Map/etc. containers which ignore the <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">.val</code> channel in their type args (or there’s none at all, as you are proposing here), accept nulls, but have a better internal organization if no nulls are encountered dynamically.</p>
<p dir="auto">I say “if we choose” because there are reasons not to choose something that tricky and dynamic. Library designers have more options if <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">.val</code> is in the type channel.</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;"><p dir="auto">…If some but not all of those
<br>
locations accept my chosen SC, my refactorings have greater friction.</p>
</blockquote><p dir="auto">If the variable is typed by a type variable, yes. But we have decided to have the exact same kind of friction
<br>
- with value class in practice because the VM is able to unmask the value class on stack but not on heap.</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">Here by “friction” I think you mean hidden costs when heap placement of a value requires separate buffering of the payload also on heap. Alert users sometimes care about such subtleties. But (here’s the key point) users who just want the types to connect things up properly can ignore hidden costs and have a frictionless experience refactoring between heap and stack. That’s a win you don’t have when every user (alert or otherwise) is confronted with SC choices to align with type choices, during refactoring.</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">- with wildcards (you have to add those pesky ? extends/super).</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">I have a separate proposal to patch that. It’s irregular but (again) visible only to the very alert. A plain value class name <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code>, when it appears as a type argument, should be treated as sugar for <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">? extends C.ref</code>. This is consistent, I claim, with the treatment of <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code> as sugar for <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.ref</code> in other contexts. It’s a little piece of the magic from Dan Smith’s thesis, applied specifically to the needs of type companions.</p>
</div></div></body>
</html>