Hacker News new | ask | show | jobs
by kevmo314 844 days ago
> Anywhere that accepts an Operation Enum type will just as happily accept an int. This is a real pain as it almost completely negates the work we have done here.

Is this a real problem? If there's a function signature that accepts `Operation`, the caller must explicitly cast the `int` to `Operation`. At that point, it's the caller's own fault.

So I'm not really following what this is solving. As demonstrated in the article, sometimes you want string constants, sometimes you want `iota`, other times you want `1 << iota`. I like that Go doesn't dictate which I have to use if I declare an "enum".

1 comments

> Is this a real problem? If there's a function signature that accepts `Operation`, the caller must explicitly cast the `int` to `Operation`. At that point, it's the caller's own fault.

You would think that, but that isn't always the case: https://play.golang.com/p/Ze3pfNEVTVs

It's very easy to create an enum value that isn't actually in the defined range

Can you explain the thought process of a developer when they write 'performOperation(2)'? What do they believe '2' signifies in this context? I struggle to believe that this could occur by accident.
You struggle to imagine a programmer passing a value of the wrong type to a function?
Or passing a wrong value and the compiler allows it because the programmer trusted the compiler to "always do the right thing".