diff options
| author | Dan Burkert <dan@danburkert.com> | 2014-09-27 14:19:19 -0700 |
|---|---|---|
| committer | Dan Burkert <dan@danburkert.com> | 2014-11-01 10:54:34 -0700 |
| commit | ca6b082c0573f9d6f6c81403ac7ea4b5b78260d6 (patch) | |
| tree | 89fc51a5a629a766949f6445f56e04b020f05d27 /src/rustllvm/RustWrapper.cpp | |
| parent | 0547a407aa03b9f1c03843aead617a2e8c5d1147 (diff) | |
| download | rust-ca6b082c0573f9d6f6c81403ac7ea4b5b78260d6.tar.gz rust-ca6b082c0573f9d6f6c81403ac7ea4b5b78260d6.zip | |
libserialize: tuple-arity should be provided to `Decoder::read_tuple`
Currently `Decoder` implementations are not provided the tuple arity as a parameter to `read_tuple`. This forces all encoder/decoder combos to serialize the arity along with the elements. Tuple-arity is always known statically at the decode site, because it is part of the type of the tuple, so it could instead be provided as an argument to `read_tuple`, as it is to `read_struct`. The upside to this is that serialized tuples could become smaller in encoder/decoder implementations which choose not to serialize type (arity) information. For example, @TyOverby's [binary-encode](https://github.com/TyOverby/binary-encode) format is currently forced to serialize the tuple-arity along with every tuple, despite the information being statically known at the decode site. A downside to this change is that the tuple-arity of serialized tuples can no longer be automatically checked during deserialization. However, for formats which do serialize the tuple-arity, either explicitly (rbml) or implicitly (json), this check can be added to the `read_tuple` method. The signature of `Deserialize::read_tuple` and `Deserialize::read_tuple_struct` are changed, and thus binary backwards-compatibility is broken. This change does *not* force serialization formats to change, and thus does not break decoding values serialized prior to this change. [breaking-change]
Diffstat (limited to 'src/rustllvm/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
