
<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="line-break:after-white-space"><div style="font-family:Helvetica,Arial;font-size:13px">I know the EG have considered pretty much everything (I’ve followed the forums all along) but I haven’t seen this discussed yet, so here goes.</div><div class="gmail_signature"><div class="gmail_signature"><br></div><div class="gmail_signature">It seems to me the novel concept of implicit for constructors may not be necessary, as (IMHO) it depends on the story that’s told about how fields are initialised. Can’t we say the following instead? For a value class Point, if it has the implicit constructor it also has a quasi-static field Point.default (I think that’s still the plan). I want to say this constructor only has 2 things special about it: it has no body, and it’s used to initialise Point.default when the class is initialised. Later, fields and array elements of type Point! are (notionally) initialised to Point.default, not by calling the constructor, which seems more like reality and like how other fields are set to null/0. So there’s nothing implicit about the constructor itself; and the creation of Point.default isn’t magic either, it’s like the creation of Point.class or enum constants - ‘just one of those things’ that happens when a class initialises.</div><div class="gmail_signature"><br></div><div class="gmail_signature">If that makes sense, I’d go for the previous constructor syntax public default Point(). Meaning simply this is the constructor used for Point.default. Or maybe even public default-0 Point() if it’s called the ‘zero instance’.</div><div class="gmail_signature"><br></div><div class="gmail_signature">As a separate but related idea: assuming the language has Point.default, it could be better to have syntax like Point!.default for the object, with Point.default meaning null (as these value classes will effectively have 2 defaults), and in general T.default for any type, e.g. double.default. That seems useful in itself, but it would also allow the simple explanation that a field or array element of _any_ type T gets initialised to T.default.</div><div class="gmail_signature"><br></div><div class="gmail_signature">Even if that’s not workable, it would make me uncomfortable if Point.default is non-null when a Point field actually defaults to null!</div><div class="gmail_signature"><br></div><div class="gmail_signature">best wishes,</div><div class="gmail_signature">JF</div><div class="gmail_signature"><br></div></div></body></html>