4 ms·
There's no such thing as a "valid" value. Values can only be valid in some context. The empty string is valid only in contexts where… it has meaning. (Quite har
by Smaug123 2y ago
There's no such thing as a "valid" value. Values can only be valid in some context. The empty string is valid only in contexts where… it has meaning. (Quite hard to say this without being obviously circular!) Golang has chosen the point of view that "in most contexts, the zero value is valid"; it is wrong about this. There are certainly some contexts where for some particular type the zero value is valid, but it is rarely true in general.
Booleans are harmful for other reasons, sometimes related to "parse, don't validate". Write a discriminated union that makes the true/false distinction meaningful, if you really do have a two-valued data type ("--dry-run" is `| Dry | Wet`, not a bool; this mistake is called "boolean blindness"). Write a type that actually contains the data you want, if the boolean is supposed to indicate the validity of some other data (`option<string>`, not `string * bool` where `something, false` implicitly means the `something` is meaningless).
- the_gipsy 2y agoI agree, it seems I wasn't clear. The values false, zero, or empty string are "valid" in most contexts. But in go, using the stdlib json package, it is not possible to distinguish a missing value from the zero value. You can use pointers in some cases, but then everything becomes a full-blown pointer for the lack of an Option<T> type, and it still doesn't fully solve the problem. When parsing "enums" in go, which are really just a type alias and some loose constants, again it's not possible to prevent zero values sneaking in with the stdlib json package. E.g. you get a value of the correct type, but it's not one of your consts, but equivalent to a new value `YourType("")`. Thus, a lot of validation is necessary, between parsing and using values.