<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jul 20, 2022, at 9:44 AM, Remi Forax <<a href="mailto:forax@univ-mlv.fr" class="">forax@univ-mlv.fr</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">And
not having .ref and .val to be types greatly simplify the model, because they is no interaction between the type checking and the storage hints, those are two separated concerns.<span class="Apple-converted-space"> </span></span></div>
</blockquote>
</div>
<br class="">
<div class="">To emphasize this point: I think we're talking about years of development time that could be cut from this project if we could live with storage modifiers rather than needing to thread the flattening information through the type system. Not to
mention the downstream simplification for all the developers that don't have to learn what a value type is.</div>
<div class=""><br class="">
</div>
<div class="">(Think about it: no Q types, no .val/.ref, no boxing, no universal generics, no new unchecked warnings, no secondary reflection mirrors, no new descriptors, no bridges. Just a storage modifier akin to 'volatile', support for that modifier in arrays,
and value classes able to opt in to allow that modifier.)</div>
<div class=""><br class="">
</div>
<div class="">But there are details to sort out, and those details will determine whether this simplifying move is a fantasy or a viable alternative design.</div>
</body>
</html>