New candidate JEP: 502: Stable Values (Preview)

[Maurizio Cimadamore]

Hi David,
thanks for reaching out -- answser inline below

On 21/02/2025 16:34, David Gregory wrote:
>> While we started working on this for MH/VH-related use cases (for 
>> instance, FFM's jextract will be a big user of stable values), we 
>> also realized that this abstraction is actually quite useful in other 
>> cases too.
>
> This is really exciting! Stable values open the door to some really 
> exciting language features, especially in functional languages.
>
> For example, something similar is used to implement the tail-recursion 
> modulo cons transformation in the OCaml compiler: 
> https://ocaml.org/manual/5.3/tail_mod_cons.html#sec:details
>
> This could enable languages hosted on the JVM to make all kinds of 
> not-quite-tail-recursive programs stack safe without using explicit 
> stacks to store the intermediate values.
>
> Is it possible that the informal rules for record components will be 
> adjusted to allow stable fields in addition to final ones?

There's different meaning for the word "trusted". If, by that, you mean 
that fields of type StableValue<X> should be trusted the same way that 
record components are trusted (e.g. where "final" really means "final"), 
this is something we can do. I believe the prototype we have today does 
that to some extent -- but we don't know yet whether that "hack" will be 
made official :-)

In a way this problem of "trust" is an orthogonal issue -- and it would 
be better to wait for better support for trusting _all_ final fields 
(not just those inside records, or those whose type is StableValue).

Cheers
Maurizio