> > Thinking only in term of constructor is only half of the story of > preconditions, > you also need precondition on setters (and getters for the defensive copy), > that's the advantage of moving the requirements in its own 'section', you can > distribute the code to the different generated part.
Yes, and also this connects with generation of destructuring match too. And yes, I want to line the story for records up with the ultimate story for how these are done more generally. And yes, I have some thoughts on this too. But, I’m trying to keep focused on the problem immediately ahead of us, so that we can make forward progress. So, let’s come back to that ... > BTW normalizing arguments is nice way to lost the trust of your users, the > behavior is obvious if you are the writer of the class and it's a real pain > if you are the poor user that had to figure out why when he send a value, the > code acts as if it is another value. So normalization should always occur at > call site and never at callee site. And it's the same issue with default > values. While I agree that there are risks to normalization, sometimes its a reasonable thing to do. I don’t want to tell users that they can’t (say) reduce a Rational to lowest terms in the constructor. So I’d like a mechanism that supports normalization where needed. So far, having thought about it for an hour, I really like the “super in the front, field initializations in the back” interpretation. Its a nice generalization of what we have already, and it does the unsurprising thing in all the use cases I’ve come up with so far.
