[flagged]
Maybe 10 more years.
type Kind enum {
Simple,
Complex,
Emacs,
}
const kindStrings [Kind]string = {
"simple",
"complex",
"emacs",
}
func (k Kind) String() string {
return kindStrings[k]
}
func t() {
var a = Kind.Emacs - Kind.Simple // a has type int and value 2
var b = Kind.Simple + Kind.Emacs // type error
var c = Kind.Simple + 1 // type error
var d = len(Kind) // d has type int and value 3
for k := range Kind {
fmt.Printf("%v\n", k) // prints what you expect it to do
}
// not sure about legality or runtime behaviour of the followng
var t = Kind.Emacs
t++
t = Kind(42)
}
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.
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;
> 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
}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
)
> 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?
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 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.
P.S generic type sets make it even better. I’ll write an update to my post these days.
I can probably easily understand borrowing. It's mostly an issue of controlling pointer aliasing wrt mutability, especially in a multithreaded context I guess.
But that gottdarn syntax... And goroutines are too nice for the type of code I use.
I'm too spoiled with Go I guess.
I think having a small standard library is actually a good thing because it encourages exploration of the space of possibilities.
For example Go’s stdlib http.HandlerFunc sucks, people instead opt for leaving it behind entirely in favour of Gin or trying to work around it with bad patterns like interface smuggling.
I don't see this as negative or "reinventing the wheel". Reinventing the wheel would be writing your own implementation, which doesn't happen if you can choose from many high-quality crates.
The cardinality of the set of "nobody uses anymore" is usually in tens of millions.
There is massive value in this.