How to implement a record de-constructor ?

forax at forax at
Tue Mar 20 17:16:26 UTC 2018

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at>
> À: "Remi Forax" <forax at>
> Cc: "amber-spec-experts" <amber-spec-experts at>
> 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.


More information about the amber-spec-experts mailing list