Make Primary Constructor an independant feature

[Remi Forax]

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

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