Compare to other enum proposals?

[ljharb]

How does this compare to @rwaldron's https://github.com/rwaldron/proposal-enum-definitions and @rbuckton's https://github.com/rbuckton/proposal-enum ?

[Jack-Works]

I have communicated with @rbuckton. I'll revisit the materials see if I can cover the support of shared structs (which @rbuckton's version indented to support). After revisiting the materials I'll update the documentation.

[rwaldron]

@ljharb thanks for the call out. My efforts have largely merged with @rbuckton's, with only a few minor nits that I think could be worked out.

Edit: If this proposal does move forward, I'd like to be included in the champion group (I'd also like @rbuckton to be present as well, but I will leave that to him).

[ljharb]

Id love to see some resolution on things like https://github.com/rbuckton/proposal-enum/issues/1 ; i haven’t gotten any sense of that merging, but perhaps it’s happened privately?

[rwaldron]

@ljharb it was mostly resolved off-line and I believe resulted in @rbuckton's Foo of Bar additions (specifically the enumMap mechanism, IIRC in https://github.com/rbuckton/proposal-enum/commit/f3a62f266e8807f29b1e916428b63ea62c39d7d2), which was close but not quite the novel thing I described with the Foo via Bar design. That difference is what I thought we could work out over time. Unfortunately, the whole effort stalled when at least one committee member vowed to block the proposal of any enum design that had default integer values 🤷

[rwaldron]

@ljharb at this point, I could probably be convinced to go along with "no default incrementing integer values", but only if the enumMap mechanism is included. This proposal is already trying to special case the creation of the values (by highjacking the syntactic space that Ron and I were working in), instead of allowing it to be a user-provided mechanism, which I can't support.

I don't want this:

enum Days for bigint {
    Monday = 0n,
    Friday = 4n,
}

I want this:

enum Days of BigInt {
    Monday,
    Friday = 4n,
}

Which gives me: Days.Monday === 0n and Days.Friday === 4n. But given no specific assignments:

enum Days of BigInt {
    Monday,
    Tuesday, 
    Wednesday,
    Thursday,
    Friday,
    Saturday, 
    Sunday
}

Would give me:

Days.Monday === 0n;
Days.Tuesday  === 1n;
Days.Wednesday === 2n;
Days.Thursday === 3n;
Days.Friday === 4n;
Days.Saturday  === 5n;
Days.Sunday === 6n;

And if I'm going to make good on my commitment to compromise, then I would expect the following to fail:

enum Days {
    Monday
}

SyntaxError: missing assignment after Monday

(or something like that)

But this would be ok:

enum Days of Number {
    Monday
}

(But also, I want of renamed to via because of is wrong thing here, and via is, by definition, the right thing)

This capability is a hard requirement.

[rbuckton]

I'd like to point out the @@toEnum approach in my proposal is heavily influenced by Python enums, but folds in Python's auto() to be built in to the syntax.

I've also been working out how to extend the syntax to support ADTs based on a conversation with Axel Rauchmeyer on Twitter a few months back. An early sketch of the idea is here: https://gist.github.com/rbuckton/4a5108fab40ac90551bf82d9884711b5

[rwaldron]

@rbuckton whoa—I like that!

[Jack-Works]

Unfortunately, the whole effort stalled when at least one committee member vowed to block the proposal of any enum design that had default integer values 🤷

Yeah, I also think auto-increment is a footgun although it is very useful. See explain in https://github.com/Jack-Works/proposal-enum/discussions/13

[rbuckton]

I wrote up another example, this time using normal classes/functions (though I think a solution that works with records/tuples/shared structs will be important in the long run):

https://gist.github.com/rbuckton/192c2922650e05a1ca9cd7c01be7fc6c

[rbuckton]

And if I'm going to make good on my commitment to compromise, then I would expect the following to fail:

enum Days {
    Monday
}

What if the default for enum Days was of ADT? Its not TS compatible (and thus would require a flag), but it would simplify the more powerful ADT-style enum case. The downside would be that non-complex enum members would probably still have a typeof of "function".

[Jack-Works]

I have updated the README. I didn't include the comparison to the previous work on this topic because I decided not to start designing concrete semantics/syntax before we figure out the design constraints.

[joshgrift]

@rwaldron @Jack-Works and @rbuckton I'd love to help push this forward, but there are a few different proposals floating around. It sounds like @rbuckton and @rwaldron are close to an agreement on the specs? What differences still remain?

[rwaldron]

@joshgrift yes, I would describe my position as close agreement with @rbuckton's latest proposal, with a few minor things to work out.