There needs to be a deterministic,
mechanically-derivable-from-the-state-vector way to construct a
record instance. Serialization, for example, would use this for
reconstructing the object; frameworks like O/R mappers would do
the same. Allowing the user to withdraw the constructor from the
API would undermine this.
Serialization is an opt-in mechanism, i've not problem with the
constructor of a record being always public if the record is marked as
Serializable.
I have a big, big problem with that. I don't want the accessibility of
the mandated members to depend on something as ephemeral as what
interfaces you implement; this is a giant leap towards the slippery
slope of "Please, can I have 37 knobs on the code generator, kthxbye".
No knobs. There are no knobs.
But i don't think it's a good idea to make all records "serializable"
(in the general sense) by default
No one is suggesting that. Serialization was an example; OR mappers was
another. These are examples of the general principle that "we want
records to be instantiable by frameworks", which means they need a way
to find the constructor reflectively.
Java serialization is not the best mechanism, mostly because of its
implementation, but at least there is one thing right, being
serializable is opt-in.
I believe we should follow the same principle by allowing the
constructor to be public or private, you are opting for being
serializable (in the general sense) or not.
Among other things, unless we're willing to have _yet a third_ default
accessibility (one for classes, one for interfaces, and yet another for
records), then the obvious thing people will type:
record R(int x) {
R { ... }
}
would leave the ctor as package-private, which is probably not what
people want either. Nope.
I sympathize with the concern that "public ctor is not the best thing to
expose". Until someone offers something better, though, this is the
best we've got so far.
