Records feedback

[Brian Goetz]

> On Nov 23, 2019, at 8:18 AM, Florian Weimer <fw at deneb.enyo.de> wrote:
> 
> On the other hand, for a record, a public constructor may not be able
> to check the record invariant efficiently based on the fields alone.

Sure, but now we’re getting so far afield of the design center for records — nominal tuples — that “just use a class” is an entirely sensible response here.  

It’s tempting to want to make records more than they are; there are so many use cases that feel tantalizingly “one step away” from what records can do.  But, having explored those use cases, they’re quite the slippery slope.  Its tempting to believe that making a small compromise will greatly expand the reach of the feature, and then people would be happier (and if this were true, we’d have considered it.)  But in reality, each compromise leaves you with another set of use cases that are just over the new line, asking for yet more compromise, until the design center is so unrecognizable that it makes it much harder for people to understand what the feature is for or how it works.  We explored a lot of compromises down this path, but none of them had an attractive enough cost/benefit to be worthwhile, so we pulled back to what was strictly justified by the design center.