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