6 ms·

> Go has constants That's literally what enums are: A set of named constants. You might be thinking of what is traditionally known as sum types, which some pe

> Go has constants That's literally what enums are: A set of named constants. You might be thinking of what is traditionally known as sum types, which some people have recently started calling enums[1]. Indeed, Go does not have sum types. [1] Presumably because of Rust using the wrong term when specifying its sum types

khazhoux 3y ago
The article is about enums, which are lacking in Go.
- randomdata 3y ago
  No, Go definitely has enums. It is sum types (that some people have recently started calling enums) that Go lacks.
  - grumpyprole 3y ago
    Go does not model enums as separate types (like e.g. Pascal), they are essentially just integers like C.
    - randomdata 3y ago
      No, Go enums are definitely separate types. Sure, technically there is also an integer (or some other base representation) hidden in there somewhere, but that's what an enumeration is. Without that you don't have an enum.
      - grumpyprole 3y ago
        Creating new types wrapping int is not really the same thing. It's not a closed set. Presumably one could define additional overlapping constants with the same integer type elsewhere?
        randomdata 3y ago
        Go types do not support value constraints, no. That has nothing to do with enums, though. That's a different feature altogether.
        grumpyprole 3y ago
        It has a lot to do with enums, especially if you are claiming statically typed enums. When defining a type, more often than not, we want to define the values that make up the set. For example, 'type boolean = true | false'
        randomdata 3y ago
        > we want to define the values that make up the set. For example, 'type boolean = true | false' Sure, or, more relevant, `type monthOrdinal = 1-12` or `type email = {string}@{string}`. Any advanced type system will allow for that, of course, but Go does not. It does not even pretend to claim to be an advanced language. It has, quite explicitly, chosen to not be. Yes, you are right that if Go had value constraints then an enum type could utilize those constraints, but, again, nothing to do with enums themselves. You are confusing unrelated features.
        grumpyprole 3y ago
        > You're confusing unrelated features Actually I think you are. For example, almost all statically typed languages since Pascal do not have value constraints but support typed enums as closed sets. There's no advanced type system needed - no need to define enums as integers and then put additional constraints in the type system to try and restrict this. There is also no need to model enums as integers in the type system in order to use integers as a runtime representation.
        randomdata 3y ago
        You can't have closed enums without value constraints. Yes, some languages have been lazy and provided value constraints only for enum types. Which is an interesting choice: Give a noose for developers to hang themselves with for every single other type other than enums – the types they are going to use most often – and not think twice, but then go full on helicopter parent when using enums – the one type that isn't particularly interesting. It's a neat parlour trick, don't get me wrong, but I guess that's why almost all of the popular statically typed languages since Pascal (C, C++[1], Typescript[2], etc.) didn't bother with closed enums. They put their time into features that actually mattered to developers instead. [1] Added later in life, granted. [2] Ironically, does support value constraints except in the case of using enum.
adamrezich 3y ago
is there any further information on why Rust and other recent languages have started using `enum` to refer to sum types? I don't use Rust or TypeScript (edit: apparently TS doesn't have this, my memory is bad) or any of those languages and it's been very strange to see this redefinition occur
- randomdata 3y ago
  Typescript has actual enums. They behave just like Go's (for better or worse). It's not clear why Rust got confused.
  - adamrezich 3y ago
    yep, sorry about that, I misremembered TypeScript as having the same "kind of enums" as Rust.
    - tubthumper8 3y ago
      TypeScript has discriminated unions if that's what you were thinking of https://www.typescriptlang.org/docs/handbook/2/narrowing.html#discriminated-unions https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...
- Quekid5 3y ago
  I think it might be due to the O'Caml influence on early Rust. They call them enums there[0]. [0] https://www.ocamlwiki.com/index.php?title=Enums_in_OCaml https://www.ocamlwiki.com/index.php?title=Enums_in_OCaml
  - ReleaseCandidat 3y ago
    They are called variants in OCaml (and inductive data types in Roqc). But way more important: this OCaml wiki is an AI generated mess full of, well, bullshit. https://discuss.ocaml.org/t/whats-up-with-ocamlwiki/13605 https://discuss.ocaml.org/t/whats-up-with-ocamlwiki/13605

khazhoux 3y ago

The article is about enums, which are lacking in Go.

randomdata 3y ago
No, Go definitely has enums. It is sum types (that some people have recently started calling enums) that Go lacks.
- grumpyprole 3y ago
  Go does not model enums as separate types (like e.g. Pascal), they are essentially just integers like C.
  - randomdata 3y ago
    No, Go enums are definitely separate types. Sure, technically there is also an integer (or some other base representation) hidden in there somewhere, but that's what an enumeration is. Without that you don't have an enum.
    - grumpyprole 3y ago
      Creating new types wrapping int is not really the same thing. It's not a closed set. Presumably one could define additional overlapping constants with the same integer type elsewhere?
      - randomdata 3y ago
        Go types do not support value constraints, no. That has nothing to do with enums, though. That's a different feature altogether.
        grumpyprole 3y ago
        It has a lot to do with enums, especially if you are claiming statically typed enums. When defining a type, more often than not, we want to define the values that make up the set. For example, 'type boolean = true | false'
        randomdata 3y ago
        > we want to define the values that make up the set. For example, 'type boolean = true | false' Sure, or, more relevant, `type monthOrdinal = 1-12` or `type email = {string}@{string}`. Any advanced type system will allow for that, of course, but Go does not. It does not even pretend to claim to be an advanced language. It has, quite explicitly, chosen to not be. Yes, you are right that if Go had value constraints then an enum type could utilize those constraints, but, again, nothing to do with enums themselves. You are confusing unrelated features.
        grumpyprole 3y ago
        > You're confusing unrelated features Actually I think you are. For example, almost all statically typed languages since Pascal do not have value constraints but support typed enums as closed sets. There's no advanced type system needed - no need to define enums as integers and then put additional constraints in the type system to try and restrict this. There is also no need to model enums as integers in the type system in order to use integers as a runtime representation.
        randomdata 3y ago
        You can't have closed enums without value constraints. Yes, some languages have been lazy and provided value constraints only for enum types. Which is an interesting choice: Give a noose for developers to hang themselves with for every single other type other than enums – the types they are going to use most often – and not think twice, but then go full on helicopter parent when using enums – the one type that isn't particularly interesting. It's a neat parlour trick, don't get me wrong, but I guess that's why almost all of the popular statically typed languages since Pascal (C, C++[1], Typescript[2], etc.) didn't bother with closed enums. They put their time into features that actually mattered to developers instead. [1] Added later in life, granted. [2] Ironically, does support value constraints except in the case of using enum.

adamrezich 3y ago

is there any further information on why Rust and other recent languages have started using `enum` to refer to sum types? I don't use Rust or TypeScript (edit: apparently TS doesn't have this, my memory is bad) or any of those languages and it's been very strange to see this redefinition occur

randomdata 3y ago
Typescript has actual enums. They behave just like Go's (for better or worse). It's not clear why Rust got confused.
- adamrezich 3y ago
  yep, sorry about that, I misremembered TypeScript as having the same "kind of enums" as Rust.
  - tubthumper8 3y ago
    TypeScript has discriminated unions if that's what you were thinking of https://www.typescriptlang.org/docs/handbook/2/narrowing.html#discriminated-unions https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...
Quekid5 3y ago
I think it might be due to the O'Caml influence on early Rust. They call them enums there[0]. [0] https://www.ocamlwiki.com/index.php?title=Enums_in_OCaml https://www.ocamlwiki.com/index.php?title=Enums_in_OCaml
- ReleaseCandidat 3y ago
  They are called variants in OCaml (and inductive data types in Roqc). But way more important: this OCaml wiki is an AI generated mess full of, well, bullshit. https://discuss.ocaml.org/t/whats-up-with-ocamlwiki/13605 https://discuss.ocaml.org/t/whats-up-with-ocamlwiki/13605