4 ms·
Also issue with golang (+ protobufs) where you can't distinguish a populated zero value from the default "not present" value.
by jallmann 4y ago
Also issue with golang (+ protobufs) where you can't distinguish a populated zero value from the default "not present" value.
- kortex 4y agoThis drives me absolutely bonkers. We had a situation in a machine learning context where we should have been treating the output of a detector as NaN (it was deliberately opting out), but instead it was falling back to zero. Last I checked (this was years ago) the way to deal with this is to wrap it in a sub-message (which are actually nullable), which is just kinda gross.
- krackers 4y agoI thought proto3 has support for optional scalar fields now (https://github.com/protocolbuffers/protobuf/releases/tag/v3.15.0 https://github.com/protocolbuffers/protobuf/releases/tag/v3....), and proto2 always had it
- bazoom42 4y agoThats why JavaScript has both undefined and null!
- deely3 4y agoDo we really need to differentiate between undef and null?
- bazoom42 4y agoNot necessarily, but it does allow a level of robustness to be able to distingish between values which have deliberately been assigned null, and values which have not been initialized correctly.
- mananaysiempre 4y agoLua does fine with only a nil, although it gets a tad annoying when you actually want to store a nil value in an array and end up creating a hole instead. (Arguably, the solution to that problem is to use your own marker object and not a nil when you need some sort of unspecified or default value which is not a literal absence of one.)
- hardware2win 4y agoC# linqs method - first or default has the same problem
- int_19h 4y agoThe method itself just uses the default value of the corresponding type. If you have a sequence of ints, and you cast it to Nullable<int> first before applying FirstOrDefault, then you can distinguish between null and 0.