Uh oh!
There was an error while loading. Please reload this page.
libserialize: tuple-arity should be provided to Decoder::read_tuple - #17595
Conversation
sfackler
commented
Sep 28, 2014
cc @erickt |
bb4ca59 to
a95778eComparedanburkert
commented
Oct 4, 2014
Rebased. |
aturon
commented
Oct 17, 2014
Ping @erickt |
erickt
commented
Oct 20, 2014
Sorry I missed this. Overall this looks good to me. Could you add a test to make sure json does a sensible thing if there are too many or not enough values to deserialize into a tuple? |
a95778e to
4151fc7Comparedanburkert
commented
Oct 24, 2014
Rebased and tests added. |
4151fc7 to
4a468d9Comparedanburkert
commented
Oct 25, 2014
Rebased and changed |
danburkert
commented
Oct 29, 2014
It's not clear to me whether these test failures are real or an aberration. None of the logs I can see show any failures. |
sfackler
commented
Oct 29, 2014
@danburkert way at the bottom: /Users/rustbuild/src/rust-buildbot/slave/auto-mac-64-opt/build/src/libserialize/json.rs:2156: line longer than 100 chars |
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]
4a468d9 to
05f6bdaComparedanburkert
commented
Nov 1, 2014
Rebased and line length issue fixed. |
…=alexcrichton 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]
Implement lifetime inferring
Currently
Decoderimplementations are not provided the tuple arity asa parameter to
read_tuple. This forces all encoder/decoder combos toserialize 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 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_tuplemethod.The signature of
Deserialize::read_tupleandDeserialize::read_tuple_structare changed, and thus binarybackwards-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]