More, to prevent PrintMonth(14), which the function would have to check for and either return an error or panic, since there is no meaningful output. In fact, it's fairly easy to see, even in this case, where the PrintMonth signature would have to return an error, when that is pretty much the only case where it would need to. With an enum as an input parameter, the PrintMonth() function would not need to have the error return value. It's the same type of philosophy around interfaces. If you accept as an input parameter an interface that has a PrintMonth() function, then you don't have to double check that the passed struct/object has a PrintMonth() function. You can just use it. If you accept a Month enum as an input parameter, you don't have to check that it's between 1 and 12 inclusive.
BTW, this isn't something I'm passionate about. I was more just answering Mike Schinkel's question about why it would be useful. On Monday, March 4, 2024 at 10:47:27 AM UTC-5 Brian Candler wrote: > On Monday 4 March 2024 at 15:18:05 UTC Jeremy French wrote: > > What I find valuable is to be able to accept an enum as a parameter to a > function, and know that it will be one of several approved values (e.g. > month of the year) > > > ISTM all that's needed is to have a way to create a named type which > cannot be assigned from the values of the underlying type, except inside a > const declaration. > > Does this represent the problem statement? > https://go.dev/play/p/kLME_dJE9a5 > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2af024e7-e7bf-4ed9-aaf4-58bade052aeen%40googlegroups.com.
