<div dir="ltr"><div>Hello dear experts,</div><div><br></div><div>I've been following the valhalla list for a number of years already and I'm quite happy with the currently proposed model, but as others I'd like to raise a concern about making .val a use-site knob instead of a declaration site.</div><div><br></div><div>I don't think there are a lot of problems, but still I think the gist of why the use-site usage of .val introduces distress for people is the following.</div><div><br></div><div>It's easy to miss .val were it should and there is no immediate indication that something is wrong:</div><div><br></div><div>When performance is not good enough, you need to profile and look for a place to insert .val. Profiling is costly, many people have software that can only be realistically profiled in production. So yes it's easy to fix in a sense, but it's hard to find where the problem is.</div><div><br></div><div>The alternative that people see is that for some types you should aggressively go through the code and append .val wherever this type is available, just to never ever have a need to profile. I envision that we will get annotations, static-analysis and even best practices to encourage this. The worst example that I can invent is something like a naming convention, so that value classes should always be named with Ref suffix:</div><div><br></div><div>value class CompexRef {</div><div>}</div><div><br></div><div>so that all actual usages will become</div><div><br></div><div>CompexRef.val v = CompexRef.of(1, 5);</div><div><br></div><div>or annotation for static-analysis tool<br></div><div><br></div><div><a class="gmail_plusreply" id="plusReplyChip-0">@</a><a class="gmail_plusreply" id="gmail-plusReplyChip-0">Always</a><a class="gmail_plusreply" id="plusReplyChip-0">UseVal</a><br></div><div><div>non-atomic value class CompexRef {</div><div>}</div><div><br></div><div>The introduction of conventions and additional tooling is understandable: it's much cheaper to solve this problem like this than to profile software on a case by case basis.<br></div><div>I think this is the main issue, even though the performance model is adequate and the use-site knob is good to tweak performance, there are still cases that can be fixed "once and for all", and people will reach to this solution no matter what. And I think language has to accommodate for this and not create a new industry of static-analysis tools.<br></div><div><br></div><div>Another similar case is missing initialization. This is not so convincing, because we have already become good at fixing NPE and we already have good static analysis tools for nullability. But still fixing missing initialization for some Complex variable based on catched NPE is much, much more costly then having some kind of static-analysis that says that Complex should always be initialized to zero. So here again there is a solution that can "fix NPE" for some areas without going case by case. And some types, like Complex, should probably be "just fixed once and for all".<br></div><div><br></div><div>So I think this is it, there are no more overlooked problems, but I think the problem stated above is serious enough to make people concerned.<br></div><div><br></div><div>If I go to a solution, then I don't think I have a perfect answer, but leaning on "code like a class works like an int mantra" maybe we can reuse the concept of "permit" from sealed-interfaces and make value companion to be explicitly named, like:</div><div><br></div><div>non-atomic value record ComplexRef(int re, int im) __permits_value_companion Complex {</div>}</div><div><br></div><div>__value_companion Complex __unboxes ComplexRef {</div><div>    static Complex of(int re, int im) {</div><div>        return new ComplexRef(re, im);<br></div><div>    }<br></div><div>}<br></div><div><br></div><div>there should be no explicit state and no constructor in the Complex value companion, all the state management is performed in normal class ComplexRef.</div><div><br></div><div>Maybe "__value_companion" should be called "primitive", because it is not a class, but something that has a "wrapper" class. We can imagine that Integer and int are defined like this:</div><div><br></div><div>value class Integer permits-primitive int {</div><div>}</div><div><br></div><div>primitive int {</div><div>}<br></div><div><br></div><div>--</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Victor Nazarov<br></div></div></div></div></div></div></div>