[coder543]

It is type safe. Any integers with a defined type cannot be used as values of type "state" without an explicit conversion occurring.

Type safety does not guarantee exhaustive matching, unfortunately, because the underlying type is still an integer, but that's a separate issue.

https://play.golang.org/p/K0m4hfmw8C1

I wish Go had proper, exhaustive enums too (sum types preferably), but you're incorrect when you say that they don't have type safety.

[tsimionescu]

You're right that you can't mix named types with the base type.

However, they are not enums in any way either, since there is no limit on their possible values to some restricted set - they really are just integers, even more than in C# or C++, even though there is no implicit conversion.

[coder543]

> they really are just integers, even more than in C# or C++, even though there is no implicit conversion.

What do you mean by this?

C#: https://repl.it/repls/ExhaustedDisgustingRam

C++: https://repl.it/repls/BackGroundedRobot

C# and C++ offer exactly the same thing that Go offers... enums that are really just integers.

You can assign arbitrary values to those C# and C++ enums, even though you're not supposed to, just like in Go.

Rust offers something truly better, where the enum abstraction doesn't leak at all.

[scatters]

In C++, you get an error at runtime: https://godbolt.org/z/C_JFez

Note though that C++ allows using enums as bitfields, so some form of loading non-enumerated values has to be allowed.

[coder543]

> In C++, you get an error at runtime

Your statement implies that errors for using invalid values are guaranteed at runtime as a feature of the language. That entire statement is incorrect.

You really don't get errors... I literally pasted a link to a working, non-erroring example in the comment that you responded to. You clearly saw the code. Did you click "run"?

You only get an error at runtime if you add "-fsanitize=undefined" (or "-fsanitize=enum"), where the compiler will inject some code into your binary.

But the error doesn't actually stop code execution: it just prints a warning!

Here is a link with the sanitizer enabled, and no warning is even printed for using an invalid value: https://godbolt.org/z/NA7FNQ

So, not only is the sanitizer not even comprehensive, it's not actually a feature of C++. It's a best-effort feature from the compiler to add a non-standard runtime code sanitizer to your binary. Warnings for using invalid values are not guaranteed.

[josephcsible]

You had to use casts to get those to compile. Go will let you shoot yourself in the foot by accidentally writing "z = 3", which is way more likely than accidentally writing "z = (Something)3".

[coder543]

The point is that those languages’ enums are very much integers too. Do those languages allow you to write out as many types of integers literally in your code? No. But that’s not the point being addressed here. You can reread the comment I was responding to, and there’s no hint that I can see anywhere that they’re talking about untyped literals.

The point I’m making is that C# and C++ enums are not exhaustive, and not guaranteed to be any particular predefined value. They’re just integers. (unlike Rust: https://play.rust-lang.org/?gist=c9e499ba8d3abe08e5e54c74f54...)

C#, C++, and Go all share the same flawed enum representation strategy. Use Rust if you want to get better enums... those other languages aren't any better for enums. C#, C++, and Go enums are all type safe, and they're all perfectly capable of holding completely unexpected values. (Although, C++ in the older permissive mode was not type safe period when it came to enums, if I remember correctly. I admit it's been long enough that I could be misremembering.)

I already addressed your point in detail with you elsewhere.

Please, by all means review the final 3 lines I wrote in this comment for more info: https://news.ycombinator.com/item?id=23715897

I agree that being allowed to write any type of integer as a literal is theoretically an ergonomic issue when it comes to enums, but it’s one issue I’ve literally never seen happen even once in practice. I point out that there are linters available to address the issue if it’s one you feel so strongly about. Surely you use linters in every language?

I have been paid professionally for years to work in both Rust and Go codebases. Linters are essential for both languages, and CI is where you guarantee that no lint-failing code is allowed to pass.

I’m well aware of Go’s flaws, but people throughout this thread (yourself included) have made tons of baseless claims about Go. Just because it’s popular to hate on a given language doesn’t make it okay to use incorrect statements for that purpose, such as saying that Go’s enums aren’t type safe. They are a separate type. The language does allow you to write integer literals of any integer type. It also does this with untyped float and untyped string literals as well, as a fun fact.

Go has a number of legitimate flaws, including the absence of both generics and sum types. You could even legitimately complain about untyped literals —- they are really nice in some ways, but they do have some trade offs.

[josephcsible]

> also will compile, because integer literals are untyped until they are used

Doesn't that make them type-unsafe? In C++ or Haskell, implicitly assigning integer literals like that isn't valid.

[coder543]

> Doesn't that make them type-unsafe?

No, it doesn't. Go's enums are type safe. You can't accidentally mix two different kinds of enum values, or accidentally use some random value of type "int" where an enum value is expected. The type system protects you from values of the wrong type being used. This was demonstrated by that Go Playground link.

Literals in Go are untyped until they're used. How they're used determines the type, and then they have a very real type, with very real type safety being enforced. So, if you're using a literal "3" where an integer of type "state" is expected, the Go language specifies that the type of "3" is "state". This is an ergonomic issue when you're expecting exhaustive Sum Types, but not a type safety issue.

Should all literal integers just always be a specific type? Let's decide that all literals should be of type "int". Great. Now you can't type a large, 64-bit integer literal to pass as a value to a function, because that would overflow the "int" type, even though the argument is desired to be "int64".

There are trade-offs to every approach.

> In C++ or Haskell, implicitly assigning integer literals like that isn't valid.

I can't comment on how Haskell does things, but C++ is more complicated than you seem to think.

https://en.cppreference.com/w/cpp/language/integer_literal#T...

"The type of the integer literal is the first type in which the value can fit, from the list of types which depends on which numeric base and which integer-suffix was used."

Go's approach is equally type safe here. It assigns the type to the literal based on the expression the literal is used in.

As I said before: I really wish Go had proper Sum Types. But enums in Go are type safe, contrary to what you have claimed in several comments here.

[josephcsible]

I'm not saying integer literals shouldn't be polymorphic. I'm just saying that polymorphism should only extend to numbers, not enums.

[coder543]

A desire to restrict the polymorphism of integers is fine, but it doesn't really change the type safety argument at all.

"Enums" here are just another type of integer, exactly like in C# and C++. They're not a separate concept. I wish Go had Sum Types or even just exhaustive, non-integer (as far as the programmer knows) enums, but neither of those are requirements to have a type safe enum. The only difference vs C++ and C# is that Go has untyped literals, which are quickly handed a type based on where they're used.

Enums in Go have type safety, which is the point you disagreed with. You can't assign values of the wrong type to an enum-typed value without explicit conversion in Go. That's type safety.

There are linters that can be used if you want to enforce more restrictions: https://github.com/THE108/enumlinter

Linters that fit your team's expectations are a good thing to use in any language, and Go is no exception here.

Would this linter be unnecessary in other languages? Sure. I would argue it's still unnecessary, because I've never even once seen anyone accidentally type a literal value in Go where they meant to use one of the predefined enum values. It's certainly possible, but it hasn't caused me any lost sleep.