Closed ghost closed 6 years ago
I don't quite understand the rationale here, and I don't understand the "fix". If a key doesn't exist, Read will return a non-nil error. If a key exists with an empty value, Read will (should?) return a nil error.
Additionally, by convention, if any function returns non-nil error, the other return values should be considered undefined. Doing any comparison on return values in the presence of a non-nil error is probably incorrect, and so I'm hesitant there, too.
I want to be able to perform one comparison, not two.
Additionally, by convention, if any function returns non-nil error, the other return values should be considered undefined.
I doubt it. AFAIK all the stdlib functions return zero value in case of an error, except some readers where partial content could be useful. But okay, feel free to close this PR, I'll just use my fork then.
Additionally, by convention, if any function returns non-nil error, the other return values should be considered undefined.
I doubt it.
(shrug) It's idiomatic. Phrased another way,
[We should] give no guarantee whatsoever of the state of the other return values in the presence of an error.
https://groups.google.com/d/msg/golang-nuts/lcZNt-nMsl0/rIzW91kICAAJ
I'll just use my fork then.
👍
This lets one more easily distinguish between a key that doesn't exist and an existing key with an empty value.