8 ms·

I'd add one more to this list: proper enum types. We use enums heavily to force devs who use our code into good choices, but the options are currently: 1) Use

I'd add one more to this list: proper enum types. We use enums heavily to force devs who use our code into good choices, but the options are currently: 1) Use int-type enums with iota: no human-readable error values, no compile-time guard against illegal enum values, no exhaustive `switch`, and no autogenerated ValidEnumValues for validation at runtime (we instead need to create ValidEnumValues and remember to update it every time a new enum value is added). 2) Use string-type enums: human-readable error values, but same problems with no compile-time guards, exhaustive switch, or validation at runtime. 3) Use struct-based enums per https://threedots.tech/post/safer-enums-in-go/ https://threedots.tech/post/safer-enums-in-go/ : human-readable error values and an okay compile-time check (only the all-default-values struct or the values we define), but it still doesn't have exhaustive switch, is a complex pattern so most people don't know to use it, and suffers from the mutable `var` issues the post author detailed. To my naive eye, it seems like a built-in, compile time-checked enum type with a FromString() function would help the community tremendously.

mseepgood 5y ago
I don't think you would need a 2.0 (backward-incompatible language change) for any of this.
- tialaramex 5y ago
  Exhaustive switch seems likely to be backward incompatible if done well. What you want here is something akin to Rust's match behaviour on enumerated types. If your alternatives aren't exhaustive, it doesn't compile. Now, Rust is doing that because match is an expression. Your day matching expression needs a value if this is a Thursday, so not handling Thursday in your day matching expression is nonsense - even though often the value of a match isn't used and might be the empty tuple it necessarily must *have a value. It seems to me that today a Go Switch statement operating on days of the week can omit Thursday and compile just fine. Exhaustive switch means that's a compile error. If your "exhaustive switch" is optional or just emits a warning, it won't catch many of the problems for which exhaustive switch is the appropriate antidote.
  - mieubrisse 5y ago
    Yep, agreed. Maybe a new hypothetical `exhaustiveswitch` keyword could be added that would be backwards compatible, but it doesn't seem very Go-like to have such similar functionality as separate keywords.
    - dpatterbee 5y ago
      I believe new keywords are not backwards-compatible as they will invalidate any code using that as an identifier.
  - mseepgood 5y ago
    > Exhaustive switch seems This would only make sense on an enum type, which would be a completely new thing, so it can be introduced without breaking backward compatibility. Constants and switch on non-enum values would stay, because they are useful independent of enum types.
    - Gwypaas 5y ago
      Also makes sense on numbers and other patterns where you can logically enforce exhaustiveness.
- smasher164 5y ago
  Sum types overlap a lot with what interfaces over. So enhancing the language with proper sum-types would benefit from enhancing interfaces and switch statements. However, zero values throw a wrench into this. The zero value of an interface is nil, so enhancing interfaces would require you to address what happens with an uninitialized variable. One of the current proposals suggests that nil continue as the zero value. They could introduce a totally different type, like a sealed interface, which doesn't require a zero value, but that distinguishes between different types of interfaces, and I'm not sure how that'll be received.
masklinn 5y ago
> We use enums heavily to force devs who use our code into good choices Beware, tho, that with many languages today you’re not really doing that even when they advertise enums e.g. in both C# and C++, enums are not type-safe (not even `enum class`). Iota is, at least, a fair acknowledgement of that. > with a FromString() function That seems like way a step too far, is there any such “default method” today? And I don’t think Go has any sort of return-type overloading does it?
- amw-zero 5y ago
  Really not sure what you're talking about. If you use enums in a real language like Swift, Kotlin, Rust, etc., you can only construct the values of the enum. There are no ways to get around it.
  - masklinn 5y ago
    > Really not sure what you're talking about. Have you considered reading?
    - amw-zero 5y ago
      Friend - this is a learning opportunity. Check the upvotes.
      - masklinn 5y ago
        > Check the upvotes. Check the upvotes on my comment.
    - lolinder 5y ago
      Have you considered elaborating? I am likewise unsure how a language could get enums wrong, even after reading your post.
      - masklinn 5y ago
        > I am likewise unsure how a language could get enums wrong, even after reading your post. By allowing any value of the underlying type, even if they were not values of the enum. The language most famous for this is obviously C: enum foo { A, B, C }; int main() { enum foo x = A; printf("%d\n", x); enum foo y = 42; printf("%d\n", y); } This will print `0` and `42` (https://godbolt.org/z/Yq8qq5bzW https://godbolt.org/z/Yq8qq5bzW), because C considers enums to be integral types and will thus implicitly convert to or from them. And as you can see from the link, there is no warning under `-Wall`. Clang will warn with `-Wassign-enum` (which is included in `-Weverything`), I don't think there's any way to make gcc complain about this. Now you might argue that this is C so obviously it fucks this up, however that C does this leads to further issues: - For compatibility with C, C# enums have the same property. I don't know about you, but that surprised me a great deal since Java has type-safe enums (even if they're not sum types). - Even more so, C++ added `enum class` in C++11, and obviously has inherited C's enums, but enum class still is not type safe, afaik the differences are that `enum class` is scoped (so in the snippet above you'd need `foo::A`) and it's not implicitly convertible with the underlying type. But it's still explicitly convertible (via a cast or list initialisation), meaning you can't assume a caller will remain within the enum.
lucian1900 5y ago
Or even better, proper sum types. They're a superset of enums anyway. https://github.com/BurntSushi/go-sumtype https://github.com/BurntSushi/go-sumtype is great, but a bit unwieldy. Language support would be much better.
- catlifeonmars 5y ago
  Proper compile time sum types would be great. I find myself reimplementing sum types at runtime far too often, especially when it comes to parsing JSON. My go to is a function with a signature along the lines of the reflect packages dynamic select: func UnmarshalOneOf(data []byte, args []interface{}) (index int, err error) Which I use like this: variants := []interface{}{ &T1{}, &T2{}} i, err := UnmarshalOneOf(data, variants) // … return variants[i]
cle 5y ago
Personally I’ve run into more problems with strict enum types in distributed systems in a team setting, than I have with Go’s lack of them. In that setting, strict enums are usually over-strict and eventually you back yourself into a corner in terms of being able to roll out new enum values. When there’s no clear winner in terms of tradeoffs, I prefer to leave it out of the language like Go has done.
- mseepgood 5y ago
  > strict enums are usually over-strict and eventually you back yourself into a corner in terms of being able to roll out new enum values. Yes, they are poison for the evolution of a public API.
  - deleted 5y ago
    [deleted]
  - amw-zero 5y ago
    Swift solved this problems with [non-exhaustive enums](https://github.com/apple/swift-evolution/blob/main/proposals/0192-non-exhaustive-enums.md https://github.com/apple/swift-evolution/blob/main/proposals...).
    - dietr1ch 5y ago
      Is it solved? How do you decide which enums are final and which ones need to be non-exhaustive to allow evolving the code? I think that Go's decision stems from protocol buffers as they allow to push new values through old binaries, which is a must once you grow enough. https://developers.google.com/protocol-buffers/docs/proto3#enum https://developers.google.com/protocol-buffers/docs/proto3#e...
      - ninkendo 5y ago
        Well, one thing is that enums are non-frozen by default, so you have to actively tag it as `frozen` if you want to put yourself in a scenario where you're never allowed to add cases. When clients use `switch` on a non-frozen enum from outside its defining module, Swift emits a warning if they don't have an `@unknown default:` case... so consumers of your enum will have to have default logic for handling new cases in order to avoid this warning. (Not for frozen enums though, for frozen ones it's enough to just cover the known cases in calling code, since the expectation will be that you can't update them.) So basically, if you don't bother thinking much about the problem, you can just avoid adding `frozen` and you'll probably get reasonable behavior where you can add more cases later. Using `frozen` should only be the case if there is some sort of logical impossibility for there to be more cases. Something like how `Optional` has .some and .none, but it's pretty obvious that nobody's going to go add a new case to it (what would a new case even mean?) Same with Result, and probably a bunch of other types I can't think of at the moment. Also worth noting that Swift treats intra-library code very differently than code that links from another library... if you use your own enums in your own module and don't make them public, it treats them as if they're always frozen... which is nice because it's your internal code and you can always update your own usages without having to worry about compatibility.
rplnt 5y ago
> no exhaustive `switch` This is what linters will do for you by default. > we instead need to create ValidEnumValues and remember to update it every time a new enum value is added Code generators are first class citizens in go, and writing an icky but reliable test won't be too hard either.
donatj 5y ago
> Use int-type enums with iota: […] no compile-time guard against illegal enum values Create a new int type and use that for your enums. While you still can create an illegal enum value, you basically have to be looking for trouble. It’s not going to happen accidentally. It’s even harder if it’s an unpunished type in a different package. See: https://github.com/donatj/sqlread/blob/91b4f07370d12d697d18a6bd7c07c48f9e33065c/scanner.go#L8 https://github.com/donatj/sqlread/blob/91b4f07370d12d697d18a...
- amw-zero 5y ago
  This compiles: type Test int const ( T1 Test = 0 T2 = 1 ) func TestSomething(t Test) {} ... TestSomething(17) So this isn't a good suggestion, because you can easily pass any int value and will not get a compiler error. You may as well be using strings at that point.
  - donatj 5y ago
    Fwiw a literal 17 in a function call, let alone anywhere outside an equation or constant definition is a code smell that should never make it past review. I see your point however.
    - amw-zero 5y ago
      Depending on code review instead of a static type system does not scale. Look at all of the memory safety security vulnerabilities that are solved by "simply making sure to manage memory correctly." Also: variableDefinedInAFarAwayModule := 17 ... TestSomething(variableDefinedInAFarAwayModule) It's not always as clear as a constant value being passed to an incorrect type.
      - donatj 5y ago
        I don't understand your example here, that's not going to compile. variableDefinedInAFarAwayModule is definitionally type int and will not be cast. It is also unpublished, so you couldn't be using it for a faraway module? Your 17 in the previous example has it's typed determined at compile time which is why it can be a problem. see: https://go.dev/play/p/jEdAhKDeLy6 https://go.dev/play/p/jEdAhKDeLy6
slx26 5y ago
Just adding to the discussion: I find this comment from Griesemer [0] on one of the github issues for enums in Golang quite insightful: >> [...] all the proposals on enums I've seen so far, including this one, mix way too many things together in my mind. [...] Instead, I suggest that we try to address these (the enum) properties individually. If we had a mechanism in the language for immutable values (a big "if"), and a mechanism to concisely define new values (more on that below), than an "enum" is simply a mechanism to lump together a list of values of a given type such that the compiler can do compile-time validation. Like with generics, I like the team's approach of taking features seriously, not adding them just because other languages have them, but actually trying to figure out a way for them to work in Go, as cleanly as possible. I think computer science, as a field, benefits from this approach. And I also dislike many things from Go, and I want "enums" badly too, but that's for another comment. [0] https://github.com/golang/go/issues/28987#issuecomment-496796680 https://github.com/golang/go/issues/28987#issuecomment-49679...
ibraheemdev 5y ago
The type sets proposal for Go has already been accepted as part of the generics proposal [0]: type SignedInteger interface { ~int | ~int8 | ~int16 | ~int32 | ~int64 } Interfaces that contain type sets are only allowed to be used in generic constraints. However, a future extension might permit the use of type sets in regular interface types: > We have proposed that constraints can embed some additional elements. With this proposal, any interface type that embeds anything other than an interface type can only be used as a constraint or as an embedded element in another constraint. A natural next step would be to permit using interface types that embed any type, or that embed these new elements, as an ordinary type, not just as a constraint. > We are not proposing that today. But the rules for type sets and methods set above describe how they would behave. Any type that is an element of the type set could be assigned to such an interface type. A value of such an interface type would permit calling any member of the corresponding method set. > This would permit a version of what other languages call sum types or union types. It would be a Go interface type to which only specific types could be assigned. Such an interface type could still take the value nil, of course, so it would not be quite the same as a typical sum type. > In any case, this is something to consider in a future proposal, not this one. This along with exhaustive type switches would bring Go something close to the sum types of Rust and Swift. [0]: https://github.com/golang/go/issues/45346 https://github.com/golang/go/issues/45346
_0w8t 5y ago
Another possibility is to use boolean flags. Of cause the compiler then will not enforce that only one of the flags is set. On the other hand on few occasions I observed how initial design with disjoint cases evolved into cases that can be set at the same time modeled with flags.

mseepgood 5y ago

I don't think you would need a 2.0 (backward-incompatible language change) for any of this.

tialaramex 5y ago
Exhaustive switch seems likely to be backward incompatible if done well. What you want here is something akin to Rust's match behaviour on enumerated types. If your alternatives aren't exhaustive, it doesn't compile. Now, Rust is doing that because match is an expression. Your day matching expression needs a value if this is a Thursday, so not handling Thursday in your day matching expression is nonsense - even though often the value of a match isn't used and might be the empty tuple it necessarily must *have a value. It seems to me that today a Go Switch statement operating on days of the week can omit Thursday and compile just fine. Exhaustive switch means that's a compile error. If your "exhaustive switch" is optional or just emits a warning, it won't catch many of the problems for which exhaustive switch is the appropriate antidote.
- mieubrisse 5y ago
  Yep, agreed. Maybe a new hypothetical `exhaustiveswitch` keyword could be added that would be backwards compatible, but it doesn't seem very Go-like to have such similar functionality as separate keywords.
  - dpatterbee 5y ago
    I believe new keywords are not backwards-compatible as they will invalidate any code using that as an identifier.
- mseepgood 5y ago
  > Exhaustive switch seems This would only make sense on an enum type, which would be a completely new thing, so it can be introduced without breaking backward compatibility. Constants and switch on non-enum values would stay, because they are useful independent of enum types.
  - Gwypaas 5y ago
    Also makes sense on numbers and other patterns where you can logically enforce exhaustiveness.
smasher164 5y ago
Sum types overlap a lot with what interfaces over. So enhancing the language with proper sum-types would benefit from enhancing interfaces and switch statements. However, zero values throw a wrench into this. The zero value of an interface is nil, so enhancing interfaces would require you to address what happens with an uninitialized variable. One of the current proposals suggests that nil continue as the zero value. They could introduce a totally different type, like a sealed interface, which doesn't require a zero value, but that distinguishes between different types of interfaces, and I'm not sure how that'll be received.

masklinn 5y ago

> We use enums heavily to force devs who use our code into good choices Beware, tho, that with many languages today you’re not really doing that even when they advertise enums e.g. in both C# and C++, enums are not type-safe (not even `enum class`). Iota is, at least, a fair acknowledgement of that. > with a FromString() function That seems like way a step too far, is there any such “default method” today? And I don’t think Go has any sort of return-type overloading does it?

amw-zero 5y ago
Really not sure what you're talking about. If you use enums in a real language like Swift, Kotlin, Rust, etc., you can only construct the values of the enum. There are no ways to get around it.
- masklinn 5y ago
  > Really not sure what you're talking about. Have you considered reading?
  - amw-zero 5y ago
    Friend - this is a learning opportunity. Check the upvotes.
    - masklinn 5y ago
      > Check the upvotes. Check the upvotes on my comment.
  - lolinder 5y ago
    Have you considered elaborating? I am likewise unsure how a language could get enums wrong, even after reading your post.
    - masklinn 5y ago
      > I am likewise unsure how a language could get enums wrong, even after reading your post. By allowing any value of the underlying type, even if they were not values of the enum. The language most famous for this is obviously C: enum foo { A, B, C }; int main() { enum foo x = A; printf("%d\n", x); enum foo y = 42; printf("%d\n", y); } This will print `0` and `42` (https://godbolt.org/z/Yq8qq5bzW https://godbolt.org/z/Yq8qq5bzW), because C considers enums to be integral types and will thus implicitly convert to or from them. And as you can see from the link, there is no warning under `-Wall`. Clang will warn with `-Wassign-enum` (which is included in `-Weverything`), I don't think there's any way to make gcc complain about this. Now you might argue that this is C so obviously it fucks this up, however that C does this leads to further issues: - For compatibility with C, C# enums have the same property. I don't know about you, but that surprised me a great deal since Java has type-safe enums (even if they're not sum types). - Even more so, C++ added `enum class` in C++11, and obviously has inherited C's enums, but enum class still is not type safe, afaik the differences are that `enum class` is scoped (so in the snippet above you'd need `foo::A`) and it's not implicitly convertible with the underlying type. But it's still explicitly convertible (via a cast or list initialisation), meaning you can't assume a caller will remain within the enum.

lucian1900 5y ago

Or even better, proper sum types. They're a superset of enums anyway. https://github.com/BurntSushi/go-sumtype https://github.com/BurntSushi/go-sumtype is great, but a bit unwieldy. Language support would be much better.

catlifeonmars 5y ago
Proper compile time sum types would be great. I find myself reimplementing sum types at runtime far too often, especially when it comes to parsing JSON. My go to is a function with a signature along the lines of the reflect packages dynamic select: func UnmarshalOneOf(data []byte, args []interface{}) (index int, err error) Which I use like this: variants := []interface{}{ &T1{}, &T2{}} i, err := UnmarshalOneOf(data, variants) // … return variants[i]

cle 5y ago

Personally I’ve run into more problems with strict enum types in distributed systems in a team setting, than I have with Go’s lack of them. In that setting, strict enums are usually over-strict and eventually you back yourself into a corner in terms of being able to roll out new enum values. When there’s no clear winner in terms of tradeoffs, I prefer to leave it out of the language like Go has done.

mseepgood 5y ago
> strict enums are usually over-strict and eventually you back yourself into a corner in terms of being able to roll out new enum values. Yes, they are poison for the evolution of a public API.
- deleted 5y ago
  [deleted]
- amw-zero 5y ago
  Swift solved this problems with [non-exhaustive enums](https://github.com/apple/swift-evolution/blob/main/proposals/0192-non-exhaustive-enums.md https://github.com/apple/swift-evolution/blob/main/proposals...).
  - dietr1ch 5y ago
    Is it solved? How do you decide which enums are final and which ones need to be non-exhaustive to allow evolving the code? I think that Go's decision stems from protocol buffers as they allow to push new values through old binaries, which is a must once you grow enough. https://developers.google.com/protocol-buffers/docs/proto3#enum https://developers.google.com/protocol-buffers/docs/proto3#e...
    - ninkendo 5y ago
      Well, one thing is that enums are non-frozen by default, so you have to actively tag it as `frozen` if you want to put yourself in a scenario where you're never allowed to add cases. When clients use `switch` on a non-frozen enum from outside its defining module, Swift emits a warning if they don't have an `@unknown default:` case... so consumers of your enum will have to have default logic for handling new cases in order to avoid this warning. (Not for frozen enums though, for frozen ones it's enough to just cover the known cases in calling code, since the expectation will be that you can't update them.) So basically, if you don't bother thinking much about the problem, you can just avoid adding `frozen` and you'll probably get reasonable behavior where you can add more cases later. Using `frozen` should only be the case if there is some sort of logical impossibility for there to be more cases. Something like how `Optional` has .some and .none, but it's pretty obvious that nobody's going to go add a new case to it (what would a new case even mean?) Same with Result, and probably a bunch of other types I can't think of at the moment. Also worth noting that Swift treats intra-library code very differently than code that links from another library... if you use your own enums in your own module and don't make them public, it treats them as if they're always frozen... which is nice because it's your internal code and you can always update your own usages without having to worry about compatibility.

rplnt 5y ago

> no exhaustive `switch` This is what linters will do for you by default. > we instead need to create ValidEnumValues and remember to update it every time a new enum value is added Code generators are first class citizens in go, and writing an icky but reliable test won't be too hard either.

donatj 5y ago

> Use int-type enums with iota: […] no compile-time guard against illegal enum values Create a new int type and use that for your enums. While you still can create an illegal enum value, you basically have to be looking for trouble. It’s not going to happen accidentally. It’s even harder if it’s an unpunished type in a different package. See: https://github.com/donatj/sqlread/blob/91b4f07370d12d697d18a6bd7c07c48f9e33065c/scanner.go#L8 https://github.com/donatj/sqlread/blob/91b4f07370d12d697d18a...

amw-zero 5y ago
This compiles: type Test int const ( T1 Test = 0 T2 = 1 ) func TestSomething(t Test) {} ... TestSomething(17) So this isn't a good suggestion, because you can easily pass any int value and will not get a compiler error. You may as well be using strings at that point.
- donatj 5y ago
  Fwiw a literal 17 in a function call, let alone anywhere outside an equation or constant definition is a code smell that should never make it past review. I see your point however.
  - amw-zero 5y ago
    Depending on code review instead of a static type system does not scale. Look at all of the memory safety security vulnerabilities that are solved by "simply making sure to manage memory correctly." Also: variableDefinedInAFarAwayModule := 17 ... TestSomething(variableDefinedInAFarAwayModule) It's not always as clear as a constant value being passed to an incorrect type.
    - donatj 5y ago
      I don't understand your example here, that's not going to compile. variableDefinedInAFarAwayModule is definitionally type int and will not be cast. It is also unpublished, so you couldn't be using it for a faraway module? Your 17 in the previous example has it's typed determined at compile time which is why it can be a problem. see: https://go.dev/play/p/jEdAhKDeLy6 https://go.dev/play/p/jEdAhKDeLy6

slx26 5y ago

Just adding to the discussion: I find this comment from Griesemer [0] on one of the github issues for enums in Golang quite insightful: >> [...] all the proposals on enums I've seen so far, including this one, mix way too many things together in my mind. [...] Instead, I suggest that we try to address these (the enum) properties individually. If we had a mechanism in the language for immutable values (a big "if"), and a mechanism to concisely define new values (more on that below), than an "enum" is simply a mechanism to lump together a list of values of a given type such that the compiler can do compile-time validation. Like with generics, I like the team's approach of taking features seriously, not adding them just because other languages have them, but actually trying to figure out a way for them to work in Go, as cleanly as possible. I think computer science, as a field, benefits from this approach. And I also dislike many things from Go, and I want "enums" badly too, but that's for another comment. [0] https://github.com/golang/go/issues/28987#issuecomment-496796680 https://github.com/golang/go/issues/28987#issuecomment-49679...

ibraheemdev 5y ago

The type sets proposal for Go has already been accepted as part of the generics proposal [0]: type SignedInteger interface { ~int | ~int8 | ~int16 | ~int32 | ~int64 } Interfaces that contain type sets are only allowed to be used in generic constraints. However, a future extension might permit the use of type sets in regular interface types: > We have proposed that constraints can embed some additional elements. With this proposal, any interface type that embeds anything other than an interface type can only be used as a constraint or as an embedded element in another constraint. A natural next step would be to permit using interface types that embed any type, or that embed these new elements, as an ordinary type, not just as a constraint. > We are not proposing that today. But the rules for type sets and methods set above describe how they would behave. Any type that is an element of the type set could be assigned to such an interface type. A value of such an interface type would permit calling any member of the corresponding method set. > This would permit a version of what other languages call sum types or union types. It would be a Go interface type to which only specific types could be assigned. Such an interface type could still take the value nil, of course, so it would not be quite the same as a typical sum type. > In any case, this is something to consider in a future proposal, not this one. This along with exhaustive type switches would bring Go something close to the sum types of Rust and Swift. [0]: https://github.com/golang/go/issues/45346 https://github.com/golang/go/issues/45346

_0w8t 5y ago

Another possibility is to use boolean flags. Of cause the compiler then will not enforce that only one of the flags is set. On the other hand on few occasions I observed how initial design with disjoint cases evolved into cases that can be set at the same time modeled with flags.