I generally tend to use enumer[0] to generate some boilerplate code that can help with addressing this, e.g. the below would compile, but would error at runtime. There are probably linters out there that could catch this. With Go, linters are generally pretty good at catching this kind of stuff.

    package main
    
    import "fmt"
    
    type Test int
    
    const (
     T1 Test = 0
     T2      = 1
    )
    
    func main() {
     t, err := TestString("T1")
     if err != nil {
      panic(err)
     }
    
     TestSomething(t)
    }
    
    func TestSomething(t Test) {
     fmt.Println(t.String())
    }

Having said that, it seems weird to have to mimic enums, as opposed to actually having it. Doesn't feel like it would add much complexity, if at all.

[0] https://github.com/dmarkham/enumer

Your point is valid, but the Go philosophy depends on you following conventions to have reliable code. This is true all over the place, e.g. you can easily ignore errors.

Other languages take a stricter approach, and maybe that's better. Not defending (although I like Go), but it's really more a language philosophy than a singular defect.

As the other commenter noted, this should fail code review and you should be using the provided constants, and it should be clear to you. And if you disagree (which again is totally valid), you should use a stricter language—there's plenty out there!

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.

I mean, that's a pretty common usage of enums, isn't it?

    TestSomething(T1 & T2)