5 ms·

How is this any different than Go's existing enumerations, aside from the enumeration also creating an implicit list structure which, while kind of neat, isn't

How is this any different than Go's existing enumerations, aside from the enumeration also creating an implicit list structure which, while kind of neat, isn't really a property of enumerations. The parent is likely lamenting that Go doesn't enforce compile-time value constraints on enumerated sets like some languages do, but many other languages don't ether. Not even Typescript does. If Typescript doesn't find it important to have such value constraints, Go most certainly never will.

Joker_vD 4y ago
> Go's existing enumerations Go doesn't have enumerations. So the first difference would be that my enums would actually exist. > implicit list structure which, while kind of neat, isn't really a property of enumerations It absolutely is, or people wouldn't have been regularly writing enums like typedef enum { KindSimple, KindComplex, KindEmacs, Kind_NUM_VALUES } Kind; which they do about half the time. > likely lamenting that Go doesn't enforce compile-time value constraints Yes, that's my complaint as well. Which is why that "not sure about legality" part in my example: you want to be able to enumerate the enum (duh), but with last_value_of_enum++ being illegal, writing for-loop with "<" is illegal too, that's why there is support for it in for-range. With incrementing (used in loops almost exclusively) taken care of, the rest of arithmetics on enums is meaningless in general except maybe in case of subtraction (when you use enums as keys/indices for a fixed-sized array) which is why I allow it — but it produces an int, of course. As for what should happen in Kind(42) example — perhaps it could work like type-assertions? k, err := Kind(42) if err != nil { return err }
- randomdata 4y ago
  > Go doesn't have enumerations. So the first difference would be that my enums would actually exist. That's obviously not true. That's what the iota dance is for. type Kind int const ( KindSimple Kind = iota KindComplex KindEmacs Kind_NUM_VALUES ) Go doesn't have a literal enum keyword, if that's what you mean, but enumerations aren't defined by having a specific keyword or specific syntax. Enumerations are a more general concept, defined as a set of named constants. The above is functionally identical to your example in C, among a host of other languages. > Yes, that's my complaint as well. Fine, but that's not a property of enumerations. If one wants support for value constraints, surely one should ask for that and not for something the language has had since the beginning?
  - Joker_vD 4y ago
    Mmm. The original comment asked for "Pascal-style enums". Those are different from C enums: they are incompatible with integers and other enums, they don't support arithmetic operations (you have to use succ()/pred() built-ins) and they contain precisely the named values (calling e.g. succ() one too many times is supposed to be a runtime-detected range error). Plus, enums being ordinal types, you could use them as array indices in type definitions, like "array[Kind] of real" (so effectively, enum range checks and array boundary checks implemented by the same mechanism). So that's what I went with, because I actually liked Pascal-style enums but thought they could be somewhat improved, so what you've read is my ideas (Go is surprisingly close to Oberon and both lack enums).
    - randomdata 4y ago
      The original comment asked for enumerations. Despite him not realizing, Go has those. It has a relatively unique syntax for defining enums, sure, but enumerations are not defined by specific syntax. They are a higher level concept that transcends any specific syntax implementation. The original comment also hinted at wanting other features that some other languages have, including Pascal, although not stating which features specifically. I expect he was referring to wanting some kind of constraint system, which is the most common feature I hear requested of Go. But that's beyond the scope of enumerations.

Joker_vD 4y ago

> Go's existing enumerations Go doesn't have enumerations. So the first difference would be that my enums would actually exist. > implicit list structure which, while kind of neat, isn't really a property of enumerations It absolutely is, or people wouldn't have been regularly writing enums like typedef enum { KindSimple, KindComplex, KindEmacs, Kind_NUM_VALUES } Kind; which they do about half the time. > likely lamenting that Go doesn't enforce compile-time value constraints Yes, that's my complaint as well. Which is why that "not sure about legality" part in my example: you want to be able to enumerate the enum (duh), but with last_value_of_enum++ being illegal, writing for-loop with "<" is illegal too, that's why there is support for it in for-range. With incrementing (used in loops almost exclusively) taken care of, the rest of arithmetics on enums is meaningless in general except maybe in case of subtraction (when you use enums as keys/indices for a fixed-sized array) which is why I allow it — but it produces an int, of course. As for what should happen in Kind(42) example — perhaps it could work like type-assertions? k, err := Kind(42) if err != nil { return err }

randomdata 4y ago
> Go doesn't have enumerations. So the first difference would be that my enums would actually exist. That's obviously not true. That's what the iota dance is for. type Kind int const ( KindSimple Kind = iota KindComplex KindEmacs Kind_NUM_VALUES ) Go doesn't have a literal enum keyword, if that's what you mean, but enumerations aren't defined by having a specific keyword or specific syntax. Enumerations are a more general concept, defined as a set of named constants. The above is functionally identical to your example in C, among a host of other languages. > Yes, that's my complaint as well. Fine, but that's not a property of enumerations. If one wants support for value constraints, surely one should ask for that and not for something the language has had since the beginning?
- Joker_vD 4y ago
  Mmm. The original comment asked for "Pascal-style enums". Those are different from C enums: they are incompatible with integers and other enums, they don't support arithmetic operations (you have to use succ()/pred() built-ins) and they contain precisely the named values (calling e.g. succ() one too many times is supposed to be a runtime-detected range error). Plus, enums being ordinal types, you could use them as array indices in type definitions, like "array[Kind] of real" (so effectively, enum range checks and array boundary checks implemented by the same mechanism). So that's what I went with, because I actually liked Pascal-style enums but thought they could be somewhat improved, so what you've read is my ideas (Go is surprisingly close to Oberon and both lack enums).
  - randomdata 4y ago
    The original comment asked for enumerations. Despite him not realizing, Go has those. It has a relatively unique syntax for defining enums, sure, but enumerations are not defined by specific syntax. They are a higher level concept that transcends any specific syntax implementation. The original comment also hinted at wanting other features that some other languages have, including Pascal, although not stating which features specifically. I expect he was referring to wanting some kind of constraint system, which is the most common feature I hear requested of Go. But that's beyond the scope of enumerations.