3 ms·
Agreed o the Enum part. It kind of sucks that if i expose a package level const (like a enum-ish thing) its not enforced by the compiler. package options
by phplovesong 5y ago
Agreed o the Enum part. It kind of sucks that if i expose a package level const (like a enum-ish thing) its not enforced by the compiler.
package options
const (
OK = iota
WARNING
FATAL
)
Later in the code
import (
"package/options"
)
func main() {
ok := options.OK // iota value 1
useOption(ok) // OK
useOption(1) // ALSO OK
}
I should be able to enforce that only values from the exposed options can be used on a type level.
- mariusor 5y agoBut you can do that if you create a type for the enum values : type errorLevel int const ( OK errorLevel = iota WARNING FATAL ) ...
- marcus_holmes 5y agoThe compiler doesn't enforce only those values being acceptable. I can do: myerrorlevel := errorlevel(3458967478) and the compiler won't complain at all. It would be good if there was some way of specifying that this type can only accept these values. Thinking about it, it's the same as nil-safe types - being able to specify to the compiler that this type cannot accept a nil value.
- mbnull 5y agounless errorlevel is exported as ErrorLevel you can only do so inside the declaring package.
- mariusor 5y agoIndeed, that was the idea behind keeping it unexported. From an external package you can only access the explicit values and the functions that accept them as parameters. The type is opaque for the developer.
- marcus_holmes 5y agoYeah, ok, fair point. That kinda works, but enums would be better