proposal: spec: enum type (revisited)

[srfrog]

I think Go is missing an enum type to tie different language features together. This is not simply a "better way to use iota" but rather a new feature to simplify code logic and extend the type system.

Note: I read #19814 and it's a good start, but I think some important parts were missing.

Proposal:

This is a backward-compatible proposal to introduce a new type called enum. With this new type will allow us to group together values and use them in a type-safe manner. It resembles a Go switch, but it defines a variable declaration (var) value. Also, there is no default enum field case. The enum-case block is a typical block, which may return the value of the field. When no return is specified, the field type defaults to int. Enum field values are not assignable, this differs from other enum implementations.

Syntax: Default (int)

// no type, defaults to int. fields with no returns will return the index ordering value.
enum Status { 
   case success: // value: 0
   case failure: //  value: 1
   case something:
     return -1 // value: -1
   case someFunc(t time.Time): // please keep reading for func below
     return int(t.Since(time.Now))
}
fmt.Printf("%T,%v", Status.success, Status.success) // output: int,0
fmt.Printf("%T,%v", Status[1], Status[1]) // output: int,1
fmt.Printf("%T", Status) // output: enum []int

Syntax: Not assignable

// this fails
Status.failure = 3
// this works
s := Status.success
fmt.Printf("%T,%v", s, s) // output: int,0

Syntax: Specific value type

enum West string {
   case AZ:
     return "Arizona"
   case CA:
     return "California"
   case WA:
     return "Washington"
}
fmt.Printf("%T,%v", West.AZ, West.AZ) // output: string,Arizona
fmt.Printf("%T,%v", West[2], West[2]) // output: string,Washington
fmt.Printf("%T", West) // output: enum []string

Syntax: Embedding - all enum types must match

enum Midwest string {
  case IL:
    return "Illinois"
}
enum USStates string {
  West
  case Midwest.IL: // "Illinois"
  case NY:
    return "New York"
}
fmt.Printf("%T,%v", USStates.AZ, USStates.West.AZ) // output: string,Arizona
fmt.Printf("%d,%d", len(USStates), len(USStates.West)) // output: 5,3

Syntax: Functions - case matches func signature, and the funcs must return values matching the enum type.

func safeDelete(user string) error {
  return nil
}
enum Rest error {
  case Create(user string):
    if err := db.Store(user); err != nil {
       return err
    }
    return nil
  case Delete(person string):
    return safeDelete(person)
}
err := Rest.Create("srfrog")

Syntax: For-loop - similar to a slice, the index match the field order.

for k, v := range USStates {
  fmt.Printf("%d: %s\n", k, v) 
}
for t, f := Rest {
  if t == 0 { // Create
    f("srfrog")
  }
}

Syntax: Switches

switch USStates(0) {
  case "Arizona": // match
  case "New York":
}
// note: West.CA is "California" but index in West is 1. Fixed example.
party := West.CA
switch party {
  case USStates.AZ:
  case USStates.CA: // match
  case USStates.West.CA:
  case West.CA:
}

Discussion:

The goal is to have an enum syntax that feels like idiomatic Go. I borrowed ideas from Swift and C#, but there's plenty of room to improve. The enum works like a slice of values, and it builds on interface. Using enum case blocks as regular blocks and func case matching allows us to extend its use; such as recursive enums and union-like.

Implementation:

I tried to reuse some of the existing code, like switch and slices. But there will be significant work for the func cases and enum introspection. I suppose that internally they could be treated as kind of a slice. Needs more investigation.

Impact:

I think this feature could have a large impact. Specially for simplifying existing code. And it could potentially render iota obsolete (?). Many devs, myself included, use const/iota blocks with string types to create and manage status flags. This is a lot of boilerplate code that could basically vanish with enums. The grouping part is also beneficial to keep similar values and operations organized, which could save time during development. Finally, the type assignment reduces errors caused by value overwrites, which can be difficult to spot.

[ianlancetaylor]

Would it make sense to use default instead of case unknown? Do you mean to imply that unknown is a pseudo-keyword?

[ianlancetaylor]

I'm sorry, I do not understand the function bit. How is that an enum?

[srfrog]

Would it make sense to use default instead of case unknown? Do you mean to imply that unknown is a pseudo-keyword?

Bad example, I guess. case unknown is actually one of the enum values. I have edited it for clarity.

[srfrog]

I'm sorry, I do not understand the function bit. How is that an enum?

The enum func use func signatures to match values. In my proposed enum we match returned values of the funcs.

// all the enum func values must return (int, error).
enum HttpCmd (int, error) {
   case Download(url, file string):
      _, err := http.Get(url)
      if err != nil {
         // another enum value (from proposal example)
         return Status.failure, err
      }
      return Status.success, nil

   case Ping(url string):
      // recursive case
      return HttpCmd.Download(url, "")
}

// usage:
code, err := HttpCmd.Ping("https://www.example.org/ping")
if code == Status.success {
  code, err := HttpCmd.Download("https://www.example.org/file.jpg", "~/Downloads/file.jpg")
  if code == Status.failure || err != nil {
     // something to do
  }
}

[creker]

How would these enums deal with unknown values? Like, for example, if we use this for protobuf or thrift and receive from the remote side an unknown enum value. How could it be handled? If we look at the languages you mentioned, they all have ways to deal with that. C# allows you to convert any value to an enum as long as their underlying types match. Swift allows many different approaches one of which involves associated values that allow you to retain the unknown value and not downgrade it to some default "unknown".

And I'm also puzzled about functions. I can't think of a real problem that it solves. And, in general, it looks weird. Enum is, basically, a type. Here you declare enumeration HttpCmd that contains not only function declaration but also definition. Then you use it as some kind of namespace to call functions from. Can I declare a variable of type HttpCmd? If I can, what can I do with that variable?

It looks like you borrowed that from Swift but there functions act like simple methods allowing you to implement things like parsing or initialization. It still looks weird but kinda makes sense and allows you to neatly group enum with its helper methods that you usually write for enums but have to put in a different place. C# has something similar allowing you to write extension methods for enums.

[srfrog]

This enum type is for grouping related values, so we want to have great flexibility how those values are generated and matched. I think this will help to reduce the number of loose global vars in code, and help with program design.

Something typical in Go code:

struct Person struct {
   Name string
   Department int
   Role Role // some struct
}
var defaultPerson Person
// ... code to manage and update Person values

Enum version:

// runtime or compile time configuration
enum Options string {
  case DefaultDept:
    return "Research"
  case Name(ID int):
    return "srfrog" // static value
  case Department(ID int):
    return getDeparmentName(db, ID)
  case DefaultRole:
    return "Student"
  case Role:
    rolech := make(chan string)
    go getRoleDistributed(42, rolech) // get from Dgraph cluster or something
    return <-rolech
}

[srfrog]

How would these enums deal with unknown values? Like, for example, if we use this for protobuf or thrift and receive from the remote side an unknown enum value. How could it be handled? If we look at the languages you mentioned, they all have ways to deal with that. C# allows you to convert any value to an enum as long as their underlying types match. Swift allows many different approaches one of which involves associated values that allow you to retain the unknown value and not downgrade it to some default "unknown".

There are no unknown values, enum is a type and all cases must exist at compile time. Therefore, the compile would error.

And I'm also puzzled about functions. I can't think of a real problem that it solves. And, in general, it looks weird. Enum is, basically, a type. Here you declare enumeration HttpCmd that contains not only function declaration but also definition. Then you use it as some kind of namespace to call functions from. Can I declare a variable of type HttpCmd? If I can, what can I do with that variable?

The func values are matched by their signature, it sounds class-ish but it's not. They would basically work equivalent to:

// func vars now
f := func(s string) error { return nil }
// enum equivalent
enum myFuncs error {
  case Something(s string):
    return nil
}

The advantage here is that the enum has a cleaner form and has the inherit qualities of slices. e.g., a series of sequential steps can be defined in an enum and ran from a for-loop. The recursive enum aspect would make for some interesting states, such as those in parsers.

It looks like you borrowed that from Swift but there functions act like simple methods allowing you to implement things like parsing or initialization. It still looks weird but kinda makes sense and allows you to neatly group enum with its helper methods that you usually write for enums but have to put in a different place. C# has something similar allowing you to write extension methods for enums.

Yes I borrowed heavily from Swift and C#, I think Swift enums are good. But with Go we need something that works better with our type system. Also, I wanted recursion to work without keywords. Finally, the const value combined with funcs might make some people happy, since they can work like read-only or immutable values.

// boats and horses can only be named once
enum Things string {
   case setName(name string):
     if !findName(name) {
       db_insert_name(name)
     }
     return name
   case Boat(name string):
     return Things.setName(name)
   case Horse(name string):
     return Things.setName(name)
}
// assume i havent named my boat
boatName := Things.Boat("Golando") // value: Golando
boatName = Things.Boat("Golando") // value: Golando

[networkimprov]

As this enum creates a namespace, did you consider struct as the namespace?

enum string { global: "nobody" }

type Person struct {
   name string
   status int
   enum int { follows: iota, leads: iota }
}

func (p *Person) x() { p.status = follows } // namespace implied
v := Person{status: follows, name: global}  // namespace implied
v.status = Person.leads

Since enum values are often associated with a struct member, this feels more ergonomic to me.

EDIT:
Maybe var (...) syntax is more appropriate here:

enum Name ( global = "nobody" ) // defines namespace & type; underlying type implicit

type Person struct {
   name Name
   status enum ( follows = iota; leads = iota )
}

v := Person{ status: follows, name: global } // namespaces implied
v.status = Person.leads
v.name = Name.global

Hm, maybe this calls for a third enum proposal :-)

[deanveloper]

This does not feel
a. Like an enumeration of values
b. Like it's idiomatic to Go

This is extremely confusing, especially the case Create(user string). I also do not like the idea of a block of code executing without me typing parentheses, such as the following:

package main

enum Foo {
case Bar:
    fmt.Println("BarBarBar")
    return 0
}

func main() {
    fmt.Println(Foo.Bar)
}

There are three possibilities as to what would happen here:

1. both BarBarBar and 0 print. This is bad, as it does not look like I have executed any code from the call site.
2. only 0 prints. This is bad, as the case Bar states that it should print BarBarBar when it is used.
3. it doesn't compile. This is bad, as it looks like everything has correct syntax, so it should logically compile.

I really don't see any good options.

[srfrog]

As this enum creates a namespace, did you consider struct as the namespace?

True, a logical namespace is made. But it's not a struct. A struct is group of fields with different names and potentially different types.

This enum is a group of fields with different names but the same type, defined in the enum definition.

It behaves like a generic slice of type, []T, or a map[int]T. Except the matching is done with values of that slice that return T.

// slice version (Go1)
const (
  ThingBoat = iota
  ThingHorse
  ThingCar
)
var Things = []string{
  "Boat", "Horse", "Car",
}
var i int
switch i {
  case ThingBoat, ThingHorse, ThingCar:
    return Things[i]
}
// enum version (Go2 proposed)
// Please feel free to write this better than me in Go1 in less than 10 lines.
enum Things string {
  case Boat:
    return "Boat"
  case Horse:
    return "Horse"
  case Car:
    return "Car"
  case Childhood(age int):
    return getThingByAge(age) // must return string
}

Since enum values are often associated with a struct member, this feels more ergonomic to me.

I relate enums to values and struct to types.

Hm, maybe this calls for a third enum proposal :-)

Maybe, give it a shot.

[srfrog]

This does not feel
a. Like an enumeration of values
b. Like it's idiomatic to Go

a) The enum behaves like an int-indexed array (Go slice), that fits the enumeration definition. You can handle them like slices; using index and iteration.
b) It's not idiomatic Go, yet. That's the goal. 🤞

This is extremely confusing, especially the case Create(user string). I also do not like the idea of a block of code executing without me typing parentheses, such as the following:

package main

enum Foo {
case Bar:
    fmt.Println("BarBarBar")
    return 0
}

func main() {
    fmt.Println(Foo.Bar)
}

There are three possibilities as to what would happen here:

1. both BarBarBar and 0 print. This is bad, as it does not look like I have executed any code from the call site.
2. only 0 prints. This is bad, as the case Bar states that it should print BarBarBar when it is used.
3. it doesn't compile. This is bad, as it looks like everything has correct syntax, so it should logically compile.

1- Yes, it prints "BarBarBar" because it's a code block. And you print the returned 0 too. That's meant to work.
2- Works like explained in #1.
3- Your code looks correct, as viewed from this proposal, it should compile.

I know the func stuff might look a bit confusing if you haven't used enums in other languages. But the best way to remember enums is that they handle values; so it's not about the matching case.