[gabereiser]

‘type Color string’ is just a type alias for string.

Likewise GLint is just a type alias for int. There are only value types (str, int, float, etc), everything else is a construct. The only true types are those value types (and pointers to them). If you call a type a Color and I call a type a Color, you are using my lib to build a program (not me using yours), you must adhere to my contract of what a Color type is to my API. Period. You can not call a function with an unknown type and expect it to behave properly.

If it panics, it’s your fault.

[kiitos]

The point here is that, in Go, "what a Color type is" isn't something that can be enforced by the compiler. And more specifically, Go doesn't allow you to define reliable enums.

[gabereiser]

It is enforced by the compiler, what it doesn't do is guarantee it at runtime. I agree with you on the enums. Go doesn't have a reliable enum construct. But the argument that I, the library author, must validate and check against any possible type of "color" you, the program author, can come up with is just crazy talk. I'll provide a Color type, I'll even pre-define some colors for you, but if you send me a Color that's rainbow, I'll panic.

[kiitos]

It literally isn't enforced by the compiler, because I can compile code which is invalid.

[gabereiser]

It’s not invalid because a string is a string. You didn’t invent a new type.