Interaction with Record & Tuple

[rricard]

Hi Jack, thanks for bringing up this proposal. It is a very interesting problem space to explore. The following comment is not an objection but something we might want to start thinking about now.

So from your README, you do bring up Record & Tuple:

work with structs proposal (constraint by \@rbuckton and \@syg), normal objects and Record & Tuples (for consistency).

This is great and we would love to help you make those enums work well with R&T!

One thing that seems to be missing right now seems to be the exact nature of the interaction between the two proposals.

For instance, from the readme:

• Support number, bigint, string, and symbol

This point seem to create a new kind of special objects that do look similar to records without being one:

Enum is a frozen, non-extensible normal object

From our point of view, enums could be Records and would naturally support the primitive restriction you brought up.

However we could also imagine enums being their own primitives like Record, Tuple & ObjectPlaceholders are likely to become.

[Jack-Works]

Oh, I didn't express that well in the readme.

Normal enum is a frozen, non-extensible normal object, and ADT enum will try to integrate with structs and Record/Tuples. The details are still unclear yet. I have talked with @hax and @rbuckton, it might be possible that both Object, Record, and Structs are not enough for ADT enum and we need a new primitive kind of specialized object (I don't like that idea though).

[rricard]

Do normal enums have a restriction on what they can contain or it that only for ADTs?

[Jack-Works]

Do normal enums have a restriction on what they can contain or it that only for ADTs?

No decision yet but I prefer normal enums can only have primitive values as their member.

[rricard]

A frozen non-extensible object that only accepts primitives inside do look very similar to a record.

For the ADT, you might be right a new type might be needed depending on the capabilities you might want to have on them.

[Jack-Works]

A frozen non-extensible object that only accepts primitives inside do look very similar to a record.

Maybe Record is good for the normal enum. (unless we want it to have some prototype or methods on it)

[ljharb]

enums will almost certainly need their own methods.

[ckknight]

I would strongly prefer to be able to store non-primitive objects within enum ADTs.

An example would be a Result ADT which could have an arbitrary Ok(value) or Error(reason)

A way to opt-in to Record semantics for a particular ADT could be interesting to explore, though.

[hax]

I hope enum could be value type (so have the equals semantic and copy by value semantic), if tuple/record finally be value type. (Immutable objects do not need copy by value semantic, but lack of equals semantic.) And I agree it's the hard requirement that ADT enum should have the ability to hold object references. And it's too cumbersome to do box/unbox manually. So I assume enum ADT would look like unions of tagged tuples with auto box/unbox. 😆