How to implement a record de-constructor ?
brian.goetz at oracle.com
Tue Mar 20 17:06:39 UTC 2018
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.
More information about the amber-spec-observers