I believe that since we are exploring the fact that record are immutable, the name
"record" doesn't suit well to the feature anymore.
I propose to rename it as tuple given that this is what this feature is, named
tuples.
It should come as no surprise that we thought about this idea quite a bit.
You have anticipated the main object: "You idiots, these aren't real
tuples." And the main response: "These are what tuples are in Java".
(just as lambdas in Java are literals for functional interface
instances.) It's a believable story.
On the other hand, there's a huge difference between this and lambdas --
the word "closure" doesn't appear in the source text. if it did, the
volume of "you idiots, these aren't real closures" would have been much
greater.
The real question, in my mind, is how it drives users to the right
mental model. For those who have no preconceived notions of what tuples
are, no problem. But for those who do -- and I think that's a lot --
the question is whether it is more work to unlearn their preconceptions
first, or to associate what records are with a relatively unpolluted name.
There are two categories of preconceived notions that we're working
against. One is the larger audience, who has a vague clue about what a
tuple is, but doesn't have a real axe to grind -- it will be some
discomfort, but they'll get over it. The other is the smaller but far^3
more vocal audience -- the Tommy Tuple clan -- who will see it as a door
permanently slammed on their favorite feature, and it will be Optional
all over again. And this group may infect the main group.
I would rather avoid picking that fight -- I don't really see the point
in it. If instead we say "records are just nominal tuples", two good
things happen:
- Those who vaguely know what tuples are will get it;
- Those who wish we had done structural tuples will have nothing to
argue with.
That's winning^2.
