enum

[satyr]

What should it do?

[gkz]

I was thinking about this to. Potentially define a constant (and frozen) ES6 set?

[andrewrk]

You could have it compile to inline constants and leave the enum out of the compiled code. However if the enum was ever exported, which I think would the the more common use case, you'd have to render the enum as an object.

[gkz]

Actually an object makes more sense than a set, you're right.

[andrewrk]

It seems like the value of this as a language feature would be limited, and as such I would opt to leave it out of coco in the interest of keeping the language smaller. Just my 2 cents.

[ksdlck]

Typically, the assumption with enums is that they are defined seperately and identically in all the places they are used--actually, that's kind of the point. If you do implement them, I would favor a semantics similar to C; assign elements the natural numbers in monotonically increasing order for all elements, allowing the users to explicitly specify values--reserving them from the set of naturals from which you draw from for the unassigned elements as necessary--for certain elements of the enum. Clearly you are free to support several assignment behaviors if you wish, e.g. attempting to assign a unique bit to each element by preceding with powers of two.

In order to support interoperability with raw JS, generated code readability, exportability, etc., these values should be turned into an object, e.g.

Colors = enum Red, Green, Blue

becomes

var Colors = {
  Red: 1,
  Green: 2,
  Blue: 3
};

I'm greatly in favor of keeping the language small, but we've already got classes and this falls within the same train of thought. Let's either have both or neither.

[ksdlck]

FWIW, I'd forego the inlining of constants on compilation. Maybe do it if the enum is defined in the same file, but the JIT optimizer on whatever platform you're using should take care of this. Inlining anywhere else causes more problems than it's worth, and even within the same file reduces code readability.