4 ms·
data interchange formats try to encode as little backwards incompatible information as possible. in this case, it would be the restriction that something is a s
by dastbe 5y ago
data interchange formats try to encode as little backwards incompatible information as possible. in this case, it would be the restriction that something is a sum type when it could have multiple fields set in the future. another example is protobuf moving to all fields being optional by default.
as for the wire format, a variant struct where you've only instantiated a single field will encode down to just about the minimum amount of information required.
- vlovich123 5y agoHave you looked at cap’n’proto. It does sum types in a very sane way.
- valenterry 5y agoThat's not contradicting though. One can always choose not to use (native) sumtypes if they are interested in extreme performance or compatibility. But logically speaking, it is _good_ that it's a restriction that a sumtype can't just turn into a multiple-fields type. Because while my software (as the consumer) might still be able to deserialize it, the assumption that only one field is set would be broken and my logic would now potentially broken. Much better if that happens at deserialization time then later one when I find out that my data is incorrect/corrupt.
- nly 5y agoAvro went the opposite way to most and just makes the concept of an optional field implementable via a union with null Non union fields can even be upgraded to unions later Personally I find the protobufs "everything is optional!" Behaviour fucking insane and awful to deal with, but it is true to the semantics of its underlying wire format.