On Mon, Mar 4, 2024 at 6:19 PM Jeremy French <ibi...@gmail.com> wrote:
> 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. The static type of an interface can be verified at compile time. The value of a variable of an enum type (or a Pascal-like subrange) type, cannot be verified at compile time in the general case. You would have to add features Go does not have (like variable immutability) and/or restrict some features for enum types that Go does have (like taking address and using unsafe). Neither looks to me very probable, at least in a short time. Those values can be however checked at runtime, similarly to array/slice index bounds checking. For subrange-like enums it's rather cheap and can be often eliminated. General, sparse-valued enums are commonly too expensive to check at runtime for the compiler. to insert them automatically. -- 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/CAA40n-X3B8je11%3DmZ98UBwWLAVkmOB-LweJCd_QU5xVqd%3Duiqg%40mail.gmail.com.
