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.
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.
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?)
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.
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.
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.
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. :-)
“keep the language simple” they said. Now Java annotations are doing a comeback. History really repeats itself, I suppose.
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.
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 vetat some point?)AFAIK, no existing check in
go vet(orgolint) requires an annotation, so I suppose this would need to set a precedent.Indeed! This could have been a lot harder (or less robust, pick your poison).
Could the Go guru/oracle be used to do this without the annotation?
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 whatgo-sumtypeis already doing.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.