Deconstructor return type as record ?

[John Rose]

On Jan 2, 2020, at 1:08 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Given that records are named tuples, does it means that a deconstructor is just a classical method with no parameter and a record as return type ?

Brian has given a good answer to this from the POV of language development,
and I agree with it.

From the POV of the JVM, looking upward through the translation strategy,
I think it is best *not* to expose or commit to unnecessary details about the
type of the return value of a deconstructor.

It would be reasonable to provide combinators which *convert* the result
of a deconstruction into some ad hoc desired nominal form, but it is not
reasonable to mandate such a nominal form for everyone to stick to,
because it will make it harder to evolve (by adding constraints to) the
runtime operations necessary to link back to result of a deconstruction.

So, from a JVM POV, a deconstructor should return an existential type
(embodied in an Object pointer) whose concrete representation is chosen
by an invokedynamic BSM, based on the exact requirements of the call
site.

There are lots of ways to fill out such a story.  Crucially, it is possible to
make nontrivial changes to a story on the fly, without recompiling the
indy sites.  Also, I don’t think it prejudices the choices we may wish to
make in the language and user model.

So:  Yes, allow the result of a match to be exposed as a requested
record type (with an optional wrapped around it if non-total),
but No, don’t mandate this in the type signatures of the involved
methods, not in the bytecode, the reflection, or the source language.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200103/112c7db3/attachment.htm>