> 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?
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).
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.
That's obviously not true. That's what the iota dance is for.
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?