3 ms·

I imagine it can be made to work, as long as you make sure the zero value is never actually valid; then you're back in the usual billion-dollar-mistake world wh

I imagine it can be made to work, as long as you make sure the zero value is never actually valid; then you're back in the usual billion-dollar-mistake world where everything is implicitly optional, rather than in the hellscape where you can never know whether you've got something meaningful in your hand or not. (I realise that Golang strongly believes zero values are usually valid, but Golang is wrong about this.)

the_gipsy 2y ago
The zero value is valid in many cases: false, 0, "", etc.
- 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 ago
    I 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.

the_gipsy 2y ago

The zero value is valid in many cases: false, 0, "", etc.

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 ago
  I 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.