1. 16
  1.  

  2. 5

    This is pretty great! I’d like to do something similar for enums, where you have a sealed interface, and export all of the valid constants. Of course, since interfaces are nilable, you don’t get any safety unless you check for nils. So, a tool, maybe even this one, or a fork of it, could exhaustively check all known values of that enum, but also ensure you’re handling nil, too.

    As much as I like this, and the enum idea though, I really would simply prefer Go to have a better type system that makes this hackery irrelevant.

    1. 2

      Yeah, I think extending this tool to support Go-style enums would be in scope. But this was the particular itch that needed scratching the most. :-)

    2. 6

      “keep the language simple” they said. Now Java annotations are doing a comeback. History really repeats itself, I suppose.

      1. 2

        I’m reasonably happy with Go as it is. (This does not mean I think it’s perfect, or ideal, or doesn’t have shortcomings.) This is a pretty small price to pay. A single annotation and one Sunday’s worth of hacking.

        1. 2

          Sorry, my tone might have been a bit harsh. It’s very cool that Go has the tools to implement something like this in a day of casual hacking.

          I enjoy using Go for some stuff too (I built an Amazon Alexa skill with it, for example), and I enjoyed how easy it was compared to the same thing in Rust, even though I have much more experience there.

          However, I dearly miss a bunch of features in Go. The biggest one being generics followed by Sum types. Your tool is going in the right direction :) (and maybe will be merged into go vet at some point?)

          1. 1

            (and maybe will be merged into go vet at some point?)

            AFAIK, no existing check in go vet (or golint) requires an annotation, so I suppose this would need to set a precedent.

            It’s very cool that Go has the tools to implement something like this in a day of casual hacking.

            Indeed! This could have been a lot harder (or less robust, pick your poison).

      2. 1

        Could the Go guru/oracle be used to do this without the annotation?

        1. 2

          I don’t understand the question. The annotation is a statement of intent by the programmer. Without that, you don’t know which interfaces to interpret as “sum types.” You could choose another heuristic I suppose, like, all interfaces with the method thisIsASumType() are interpreted as sum types. But that seemed a little uncouth to me.

          With that said, I’m not actually familiar with the Go guru/oracle (I’ve only heard of it in passing). It looks like it’s just using the standard go/{ast,parser,types} packages internally, which is what go-sumtype is already doing.

          1. 1

            IIRC, Go guru can tell you all the concrete types an interface value may hold by doing whole program analysis. If you you check a switch handles all of these you will detect the error automatically.