struct.new_default vs. immutable fields

[jakobkummerow]

(This is another bit of feedback from the J2CL team.) Consider the current situation:

• there are two ways to allocate structs: struct.new_with_rtt, where initializer values have to be provided for all fields, and struct.new_default_with_rtt, which default-initializes all fields. The latter is illegal for non-defaultable fields, and usually non-sensical for immutable fields (because an immutable field that's stuck on its default value provides quite limited usefulness).
• for subtyping, mutable fields are invariant, immutable fields are covariant. IOW: a subtype may declare a field with a type that's a subtype of its supertype's corresponding field only if that field is immutable. A prime use case for this is feature is the "vtable" field in structs, where a subtype's vtable is typically a subtype of its supertype's vtable (adding a few methods).

The consequence is that even though Java's field initialization semantics are a pretty good fit for struct.new_default_with_rtt, any object with a vtable currently must be allocated with struct.new_with_rtt and explicit initializer values for every field. Having to explicitly provide all these zeros/nulls leads to considerable code size increases. (I don't have hard numbers, sorry.)

It would be nice to have a sort of hybrid instruction for struct allocation, that consumes explicit initializer values for all immutable fields, and default-initializes the mutable fields. Can we add that to the proposal?

Maybe a slight tweak to make it more general would be even better: explicit initializers for immutable and non-defaultable fields.

(Footnote: we could(/should?) drop "_with_rtt" from the allocation instructions' names now.)

[Horcrux7]

same like #174

[jakobkummerow]

Oh, yes. Let's keep the conversation there then.