<div dir="ltr"><div>I've been following the valhalla-development for a very long time, and have also posted quite a few comments, some of them raising valid concerns, some of them proving my ignorance.</div><div><br></div><div>This comment hopefully falls into the first category: <br></div><div><br></div><div>My concern is that allowing access-restriction for a value-type's "companion-type" is a severe case of "throwing the baby out with the bathwater".</div><div><br></div><div>Yes, I know what it is supposed to achieve: prevent users from accidentally creating zero-initialized values for value-types "with no resonable default".</div><div></div><div><br></div><div>However, the proposed solution of hiding the companion-type will force programmers to use the reference-type even if they do not want to.</div><div>Please have a look at the following class "Accumulator". It assumes that "Sample" is a value-class in the same package with a non-public companion-type.</div><div>The Javadoc must now explicitly mention some pitfalls that would not be there if "Sample.val" were accessible.</div><div>Especially the necessary precaution about the returned array-type is rather ugly, right?!</div><div><br></div><div>public class Accumulator {</div><div>   private Sample.val samples;<br></div><div><br></div><div>/**</div><div>Yields the samples that were taken.<br></div><div>Note: the returned array is actually a "flat" array! No element can be null. While processing this array, do not try to set any of its elements to null, as that may trigger an ArrayStoreException!</div><div>*/<br></div><div>public Sample[] samples() {</div><div>    return samples.clone();<br></div><div>}<br></div><div></div><div>}</div><div><br></div><div>To sum it up, my proposal is:</div><div><br></div><div>1. Make the companion-type public always.</div><div>2. When introducing value-classes, document the risks of having "uninitialized" values under very specific circumstances (uninitialized fields, flat arrays).<br></div><div>3. Let the compiler treat fields of companion-types like final fields today, i.e. enforce initialization. <br></div><div>4. The risk of still encountering uninitialized fields is really really low, and is, btw, absolutely not new.<br></div><div>4. Provide the users with a convenient API for creating arrays with all elements initialized to a specific value.</div><div>5. In Java, one could possibly also use this currently disallowed syntax for creating initialized arrays: new Sample.val[20] { Sample.of("Hello") };<br></div><div><br></div></div>