Inline Record

[John Rose]

On May 7, 2020, at 6:47 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> The implementation in Object is 
> 
>     public boolean equals(Object obj) {
>         return (this == obj);
>     }
> 
> 
> This _already_ has exactly the default semantics we want for both inlines and identities.  Records layer their implementation atop it, regardless of inline-ness.  

Yes, and it would be highly counterproductive to back away from
that hard-won ground.  You have found the un-bake-able center
of my half-baked proposal.

OTOH:  The hardwired behavior of inline types, and the softwired
behavior of record types, and the other wirings that Kasper eagerly
pointed out, are all parallel, and someone (maybe JDK maybe a layer
atop) should factor that parallelism into a flexible library.  And we
should continue to provide appropriate sites (indy, ClassValue,
later bridge-o-matic and/or species) to hook up the custom wiring.

Example of overlap between inlines and custom wiring:  Suppose
a user wanted (for some reason) the toString/equals/hashCode of
some inline class to be the default behavior for *all fields but one*,
and that one is (say) an array, for which the Arrays::toString/eq/hC
is to be referred.  Factoring that well would require a reference to
the default behavior of inline types as if it were just another
off-the-shelf library behavior, even though it is hardwired.
A similar comment applies to record classes.

— John