Serde support

[sffc]

@gregtatum said in unicode-org/icu4x#480 that he can't put a TinyStr into a serde struct field because TinyStr doesn't support serde. We should add serde to TinyStr.

We could make the serialized representation either an integer or a string. I favor a string because it is more human-readable. In certain serialization forms, storing the integer form may be a bit smaller, either because you can omit the "" or the string length header, but I don't think that's worth the readability. On the other hand, we could allow both forms and have a serde attribute that lets you switch between them when serializing.

[zbraniecki]

Can we do both? The advantage of int is zero cost deseralizing.

[sffc]

Can we do both?

We could, if we think it's useful.

The advantage of int is zero cost deseralizing.

It's not zero-cost, because we still have to validate it.

[sffc]

Another advantage of strings is that it would make it friendlier when consuming serialized data from other platforms that don't have TinyStr. The integer representation is sort-of internal to TinyStr in Rust.

[sffc]

Thoughts on starting with string serialization, and considering it a feature request to add integer serialization?

[gregtatum]

starting with string serialization, and considering it a feature request to add integer serialization

I agree with this approach.

[zbraniecki]

We can have an unchecked deserialize from int. But i agree we can start with string!

[Manishearth]

This works for me!

[Manishearth]

I can make a quick PR

[Manishearth]

We can use Serializer::is_human_readable to serialize to both strings or integers depending on what the serializer type is

[sffc]

I like that! If we do it, I would still prefer to validate the integers when deserializing, because data can come from unknown sources. If we want to do unchecked deserialization as Zibi mentioned above, that should be an opt-in mode.

[zbraniecki]

If we want to do unchecked deserialization as Zibi mentioned above, that should be an opt-in mode.

Sure, I agree. I believe that in environments where both input and output is guaranteed to be cohesive, the huge win of TinyStr is that it is an int that can be zero-cost deserialized. I'm ok with it being opt-in.

[Manishearth]

I like that! If we do it, I would still prefer to validate the integers when deserializing, because data can come from unknown sources. If we want to do unchecked deserialization as Zibi mentioned above, that should be an opt-in mode.

Oh yeah we can never do this unchecked, but either way we're validating, this way we can validate a little less 😄