How to implement a record de-constructor ?

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 20 Mars 2018 18:06:39
> Objet: Re: How to implement a record de-constructor ?

> Your point is noted that the notion of a record deconstructor is a
> simpler case of general matchers.  However, is there an immediate need
> for explicit record deconstructors, since the compiler can generate the
> obvious one?  And if there is an immediate need, wouldn't it likely be
> motivated by the need for some of the more advanced features
> (partiality, snapshotting, etc)?
> 
>> if a de-constructor is inlined by the VM the same way getter is inlined by the
>> VM, i.e. most of the time,
>> and if the de-constructor has no side effect (otherwise you have bigger problem
>> that just a performance issue) then the VM will remove unused computation,
>> share common sub-expressions, etc.
> 
> I would love to buy this, but I don't.  The expensive actions of dtors
> are likely to be allocating and copying stuff; even if the results are
> unused, there are still many reasons why the JIT might not elide the
> allocation and copying.

Apart if people still write side effects in their constructor in 2018, it should not be an issue,
we are still missing frozen arrays but immutable collections (List.of+List.copyOf) is a good enough replacement.

Rémi