[vm] ☂️ @pragma('vm:deeply-immutable')

[dcharkes]

Filing a tracking issue for expanding the feature-set of @pragma('vm:deeply-immutable').

https://dart-review.googlesource.com/c/sdk/+/354902 Introduces basic functionality.

• Deeply immutable classes can have fields which are deeply immutable.
• Deeply immutable classes can extend other deeply immutable classes.
• Allow type parameter types in fields of deeply immutable classes.

Not covered in this CL, but could be covered:

• Allow using deeply immutable classes across libraries.
• Allow mixin in deeply immutable classes. (Requires allowing deeply immutable classes across libraries, mixins can't be final or sealed.)
• Allow record types in fields of deeply immutable classes.

[dcharkes]

Note that the deeply immutable bit is lost in AppJIT snapshots currently:

• [vm] AppJIT snapshot loses ImmutableBit of objects #55136

This doesn't really matter for the use case with native finalizers (#55062 (comment)), because pointers to native memory cannot be part of snapshots.

[nielsenko]

@dcharkes Would it be an idea to have a marker interface that implies deep immutability? That way it would be possible to create generic classes that can be annotated with @pragma('vm:deeply-immutable') by constraining the type arguments on this marker interface. Could be useful for creating higher order immutable data-structures that can be shared efficiently across isolates.

[dcharkes]

How is that different from allowing a type argument bound which is annotated with @pragma('vm:deeply-immutable') with the regular subtyping rules? We already support having a field and enforce the subtyping rules.

• Allow type parameter types in fields of deeply immutable classes.

[nielsenko]

The difference would be that types like int, String, etc. should also implement this marker interface. While I can define my own DeeplyImmutable interface I cannot make the framework classes implement it.

[dcharkes]

The difference would be that types like int, String, etc. should also implement this marker interface.

That's a rather invasive change. We've explored something similar in https://github.com/dart-lang/language/blob/main/working/333%20-%20shared%20memory%20multithreading/proposal.md

While I can define my own DeeplyImmutable interface I cannot make the framework classes implement it.

Why not? Because you don't own the classes? or you own them but they are in a different package?

If the latter, we should address:

• Allow using deeply immutable classes across libraries.

So far we hadn't done that due to the concern of users of libraries breaking libraries by adding new subclasses/implementations that are not deeply immutable. But @mkustermann was recently arguing to remove that restriction.

[nielsenko]

Why not? Because you don't own the classes? or you own them but they are in a different package?

Because I don't own them. The way I read this issue, the cross library feature is already on your list of proposed features.

I read through the multiprocess proposal that was written up by @mraleph, and I see how it is related to his Sharable interface. Anyway, happy to hear you are already thinking about this, even if it may not happen.

[nielsenko]

For the record this snippet illustrates the issue I'm talking about

@pragma('vm:deeply-immutable')
final class DeeplyImmutable {
  const DeeplyImmutable();
}

@pragma('vm:deeply-immutable')
final class Node<T extends DeeplyImmutable> {
  const Node(this.value, this.next);
  final T value;
  final Node<T>? next;
}

// zero-cost extension types does not allow us to introcuce new marker interfaces
/* 
@pragma('vm:deeply-immutable')
extension type ImmutableInt(int value) implements int, DeeplyImmutable {}
*/
// so we need a full wrapper class like:
@pragma('vm:deeply-immutable')
final class ImmutableInt extends DeeplyImmutable {
  const ImmutableInt(this.value);
  final int value;
}

void main(List<String> arguments) {
  // This will not compile, as int don't implement the marker interface
  // final n = Node(1, Node(2, null));

  // This works, but introduces a wrapper object for every int
  final n = Node(ImmutableInt(1), Node(ImmutableInt(2), null));

  print(n.next?.value.value);
}

[mkustermann]

The difference would be that types like int, String, etc. should also implement this marker interface. While I can define my own DeeplyImmutable interface I cannot make the framework classes implement it.

For now this is a VM-specific feature and use cases are limited. This is why we decided to go initially with a @pragma(). If we made a marker interface and made String / ... implement it - it would become effectively a language feature - that would require much more discussion with language & library teams, ...

If the shared memory multithreading effort (currently in prototyping stage) will eventually land for end users, then there may not actually be a need for this deep immutability anymore - as what would be annotated with deep immutability can then be instead annotated with sharability (and get the same effect when sending across isolates - namely that they are shared).

So I think it makes sense for us to wait for the shared memory multithreading effort to be further along. If that effort doesn't result in shipping anything, the argument of making deep immutability more of a library & language feature is stronger.