Do we really need the extra "with Creator" syntax for ADTs?

[Jamesernator]

In the current proposal we have additional syntax for creating a separate factory for instances with the enum being a kind of brand thing. But wouldn't it be simpler if we just had a single name for an enum i.e. Message and had the keys as static properties of the functions (or similar) i.e.:

// Changed "for symbol" to "for function" here to declare an ADT enum
enum Message for function {
    Quit,
    Move { x, y },
    Write(message),
    ChangeColor(red, green, blue),
}

const quit = Message.Quit();

quit.type === Message.Quit.type;

Alternatively we might not even need the branding symbol and could just use something like a static method:

const quit = Message.Quit();

console.log(Message.Quit.isQuit(quit));

Or possibly just using something akin to .constructor i.e.:

quit.constructor === Message.Quit;

[Jack-Works]

It is a possible design. In @rbuckton's version of ADT enum, it works in this way. I design it as two separate things because I have some concerns about this design. If a result of ADT is sent across the ShadowRealm, it will be not matchable by the combined design because the constructor cannot be sent across the ShadowRealm.

If we have two separate things, although it's not possible to match by the constructor like this (because ShadowRealm won't clone @@matcher on the constructor when MessageCreator is a cross-ShadowRealm function):

match (value) {
    when MessageCreator.Write(message): ...
}

But it's still possible to match like this: (Message is a plain object and can be converted into Record&Tuples therefore it can send across the ShadowRealm and keep the ability to match the tag)

if (value.type === Message.Write) {
   ...
}

[Jack-Works]

The problem is how it matches. Currently in the pattern matching proposal, matching like this requires a Symbol.matcher function on the matchee. When the function sends across ShadowRealm, the Symbol.matcher property on the Message.Quit won't be cloned.

[ljharb]

Why would we need the matcher protocol?

I'm not actually sure why we'd want non-primitive enum values - but everything has leaf matcher syntax or guards already, so I don't think there'd need to be any special affordance for enums in pattern matching.

[rbuckton]

If we have two separate things, although it's not possible to match by the constructor like this (because ShadowRealm won't clone @@matcher on the constructor when MessageCreator is a cross-ShadowRealm function)

A ShadowRealm can't return a non-callable object anyways. If ADT enum values are non-primitive, then they couldn't be passed in or out of a ShadowRealm at all. If ADT enum values are primitive (as some variation of a Record or Tuple), then we could define the semantics within the spec to handle how they are unwrapped and how a @@matcher might then apply:

// my-enum.js
export enum Message for function {
  Quit,
  Move{x,y},
}

// inside-code.js
import { Message } from "./my-enum.js";

export function getMessage() {
  return Message.Move({ x: 10, y: 10 });
}

export function sendMessage(msg) {
  match (msg) {
    // ok, uses `Message.Move[@@matcher]` which is local to realm and is spec'd to handle the value
    when (Message.Move{x, y}) { ... }
  }
}

// main.js

import { Message } from "./my-enum.js";

const realm = new ShadowRealm();
const getMessage = await realm.importValue("./inside-code.js", "getMessage");
const sendMessage = await realm.importValue("./inside-code.js", "sendMessage");

match (getMessage()) {
  // ok, uses `Message.Move[@@matcher]` which is local to realm and is spec'd to handle the value
  when (Message.Move{x, y}) { ... }
}

[Jack-Works]

A ShadowRealm can't return a non-callable object anyways. If ADT enum values are non-primitive, then they couldn't be passed in or out of a ShadowRealm at all. If ADT enum values are primitive (as some variation of a Record or Tuple), then we could define the semantics within the spec to handle how they are unwrapped and how a @@matcher might then apply:

If we'd allow Record as the return value of the ADT enum value, I don't think it can have a unique @@matcher unwrapping behavior because all Record has the same prototype (null IIRC?). I don't like the idea of "variation" of Record because it actually added a new kind of value type into the language that is very similar to the Record.

If we use struct/shared structs, we need to also have a shared function otherwise @@matcher won't be able to pass across the realm.

[ljharb]

Records are primitives, so it wouldn't need to defer to the protocol there; there'd just be a hardcoded algorithm.