Make Primary Constructor an independant feature

[Brian Goetz]

> I think there is a merit to separate the primary constructor feature from other features of a record.

You could be saying one of two things here:

  - Let's streamline generation of constructors, as record constructors 
do, by allowing some way of indicating that parameters are bound to 
fields, that all classes can use.
  - Let's define a different top-level streamlined idiom, `class 
X(fields)`.

For the first, I agree, and already have most of a design story for 
this, but am deliberately holding it back because we are already deeply 
in danger of drowning in "how about this (mostly-syntax-oriented) 
feature" and not ever delivering anything. In fact, if you go back to my 
early talks about Amber several years ago, you'll note that I said 
"Records are almost surely a 'macro' for a set of finer-grained features 
that can be applied more generally."  Of the various pieces, 
"field-bound constructors" are the simplest, and they carry over almost 
directly from records.

As to the second: this is a bottomless pit of worms (I went down that 
route, didn't like it.)  Various problems:
  - The fields don't belong up in the header, if they are not part of 
the classes API.
  - Once you admit mutable state, you quickly get mired in "but I want 
setters for these fields", "but I want my getters to be protected", "but 
I want only these fields to participate in equals/hashCode", etc.

What you've basically said here is "Let's throw records in the garbage 
and design something new, more like "case classes"."  (I know you 
probably didn't mean to say that, but that's really what you're 
suggesting.)

Records work because all the protocols (representation, construction, 
deconstruction, equals, hashCode, toString) are all derived from the 
_same_ description.  Once once departs, the chances that another wants 
to depart is very high.  At which point, you either end up at a macro 
generator with too many knobs (more than zero is probably too many), or 
you end up with an assortment of lower-level features like "make me a 
constructor", "make me an equals/hashCode", etc.

Records also work because they have clear semantics.  Once you start to 
get into macro-generation land, syntax takes over, and you lose the 
guiding light of semantics.

I think the latter path -- let's find the low-level features that 
records are really a bundle of -- is a much more sound one.  And I'm 
willing to walk it, but not right now.


> This afternoon while fixing a bug, i took a look to the classes around to see if it was possible to transform them to records. But i've found that in more than half of the cases, the classes were not representing data but just carrier so having the getters, hashCode and equals automatically generated was the factor that hamper me to transform the classes into records.
>
> Given that a record is a data carrier, i'm wondering if it makes sense to say that a record = data + carrier i.e. to separate the data part (getters + equals + hashCode) from the carrier part (the initialization using a primary constructor). The idea is that a primary constructor can be applied not only to records, but also to classes, enums and later value classes.
>
> Here are some examples,
>    For a result of a function, having an equals/hashCode can be harmful (maybe the error code is not stable)
>      class Result(int value, int errorCode);
>
>    For most of the structural patterns, having getters is not helpful
>      class UserProxy(User user) implements User {
>        UserProxy {
>          requireNonNull(user);
>        }
>        ...
>      }
>
>    An enum that stores an integer, all constants have to initialize the value
>      enum Flag(int flag) {
>        READ(8), WRITE(16)
>        ;
>
>        public boolean isAllowedBy(int flags) {
>          return flags & flag != 0;
>        }
>      }
>
> Rémi
>
>