<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <blockquote type="cite"
      cite="mid:668192015.2065330.1567710614128.JavaMail.zimbra@u-pem.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size:
        12pt; color: #000000">
        <div data-marker="__QUOTED_TEXT__">
          <blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
            <div class=""><br class="">
            </div>
            <div class="">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.</div>
          </blockquote>
          <div><br>
          </div>
          <div>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.<br data-mce-bogus="1">
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    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.  <br>
    <br>
    <blockquote type="cite"
      cite="mid:668192015.2065330.1567710614128.JavaMail.zimbra@u-pem.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size:
        12pt; color: #000000">
        <div data-marker="__QUOTED_TEXT__">
          <div>But i don't think it's a good idea to make all records
            "serializable" (in the general sense) by default</div>
        </div>
      </div>
    </blockquote>
    <br>
    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.  <br>
    <br>
    <blockquote type="cite"
      cite="mid:668192015.2065330.1567710614128.JavaMail.zimbra@u-pem.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size:
        12pt; color: #000000">
        <div data-marker="__QUOTED_TEXT__">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.<br
            data-mce-bogus="1">
          <div>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.<br
              data-mce-bogus="1">
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    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:<br>
    <br>
        record R(int x) {<br>
            R { ... }<br>
        }<br>
    <br>
    would leave the ctor as package-private, which is probably not what
    people want either.  Nope.<br>
    <br>
    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.  <br>
    <br>
  </body>
</html>