Is it not somehow redundant with the record & tuple proposal ?

[lifaon74]

It looks very similar of the record & tuple proposal: https://github.com/tc39/proposal-record-tuple

Your proposal is using prototypes and inheritance instead of plain object. However, it feels better tu use a 'record' instead of struct ? (performance wise, readability and immutability). Do I miss something ?
What feels interesting in this proposal is the possibility to "share" these objects, but we could apply the same logic to 'records' instead

[syg]

The proposals solve different problems. Records and tuples are all about value semantics (i.e. no identity) and immutability. This proposal, in contrast, is all about predictable layout of objects with mutability and identity that can be concurrently accessed.

It's possible that some use cases can overlap, but my hunch is those use cases are the ones that already overlap today where you can use plain objects or a Record. You'd use a Record if you want the immutability and value semantics, and a plain object if you don't.

As for performance, speaking as an implementer, it is unlikely records and tuples will be faster in general.

Does that answer your question?

[lifaon74]

Yes it answers my question. However, for me tuple and records will be probably faster as they would be converted as fixed length bytecode (ak: c++ struct) by the JIT compiler. I may be wrong.

I agree that having some mutable struct would be great (somehow archived by record when spreading), but currently, it feels like (on my point of view) that using classes and inheritance for that, sounds a little wrong.
For me a struct should not have any constructor nor inherit from something else. It should only describe its shape (properties).

[robbiespeed]

It's possible that some use cases can overlap, but my hunch is those use cases are the ones that already overlap today where you can use plain objects or a Record. You'd use a Record if you want the immutability and value semantics, and a plain object if you don't.

It seems like this proposal could allow implementing immutable records and tuples in user land, with the same benefits. Might be a good use case to explore. I'd rather have one syntax (structs) that can accomplish both goals, rather than 2 separate ones.

[hax]

Note, it seems R&T proposal has already been blocked (mainly by engine vendors).