[records] Summary so far

[Gavin Bierman]

Dear Experts:

In [1] Brian asked for comments on some remaining design decisions concerning
records (and asked for any new ones that you'd like to raise). 

First, thank you for your feedback so far! I have been through the threads, and
tried to summarize the question and the current status below. Of course,
these decisions are not set in stone, but the point of this email is to warn you
that they are hardening :-) So, if you disagree, or would like further
discussion, *now* is the time to speak up!


Q1. Should the distinguished supertype of records java.lang.Record be
renamed?

    [Since the original post, it seems that inline types will be able to inherit
    from abstract classes.]

    Is the name "Record" a good one? It has good clash
    potential :-) possible alternatives are RecordClass, or AbstractRecord?

    A: No consensus so far. 

Q2. Accessibilty of mandated members.

    Currently the mandated members are public regardless of the accessibility of
    the record type. What should be the default accessibility for record
    members? 

    A: Currently the most popular proposal is that mandated members get
    accessibility of the record type. Other members get package level
    accessibility as per a regular class. (Note: it should be legal for explicit
    declarations of mandated members to specify something _more_ accessible
    (same rules as overriding.) )

Q3. Nesting.

    A: We are working on a new spec that removes a lot of restriction regarding
    nested classes/records.

Q4. Abstract records.

    Should we allow the declaration of abstract classes, possibly supporting
    some form of record subtyping?

    A: No support for this.

Q5. Deconstruction patterns.

    A: We will be proposing deconstruction patterns in the patterns v2 preview.

Q6. @deprecated

    Should we allow record components to be marked as @deprecated? 

    A: We don't want to add any additional support for @deprecated beyond the
    fact that it is an annotation and it can be inspected via reflection. 

Q7. .equals and .toString are slow.

    Remi [2] points out that the current implementations of .equals and
    .toString are slow.

    A: We will look into this. 

Q8. Translation strategy.

    John [3] suggested changing the compilation strategy of records so we can
    future-proof the evolution of members from the record supertype. 

    A: No change.

Q9. Hashing.

    John [4] proposed weakening of the .hashCode spec.

    A: Agreed. John has written candidate text [5].

Q10. Special annotation for explicit declaration of accessors. 

    Tagir [6] proposes a new `@RecordAccessor` annotation to mark explicit
    accessors, much as `@Override` is used to mark method overrides.

    A: Rather than introduce a new accessor, we will consider extending the
    meaning of the `@Override` annotation to include this case.

Q11. Changing the spec of .toString method

    We should weaken the spec of the .toString method so it explicitly states
    that the form of the string produced is subject to change and can not be
    relied upon.

    A: Agreed.

Q12. Transactional methods

    Canonical constructors are an instance of a general pattern where a set of
    variables are in scope for a given block, and assigned values at the end. 
    This could be a useful abstraction to be given first-class representation. 

    A: No change. More research needed. 

Q13. Factory methods instead of constructors.

    Should "new R(v1, ..., vn)" be compiled to a factory method, to allow
    future-proofing with inline types?

    A: No change for now.

Thanks for your comments and discussions so far. If you disagree with anything
written here, please reply!

Thanks,
Gavin


[1] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-January/001913.html
[2] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-January/001943.html
[3] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-January/001937.html
[4] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-January/001935.html
[5] http://cr.openjdk.java.net/~jrose/draft/record-contract
[6] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-January/001931.html