On Jan 2, 2020, at 1:08 PM, Remi Forax <fo...@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
