Optionally implement Schema for uuid::Uuid

[zeenix]

It's a very commonly used type so it makes sense to provide optional support for it out of the box.

[netlify]

✅ Deploy Preview for cute-starship-2d9c9b canceled.

Name	Link
🔨 Latest commit	400a4f2
🔍 Latest deploy log	https://app.netlify.com/sites/cute-starship-2d9c9b/deploys/66954a3ceb02f30008eebc8e

[jamesmunns]

I will plan to merge this in a bit, but this impl is wrong, I believe. Uuid serializes to a [u8; 16], and a bytearray is basically a &[u8]. The former does not serialize its length, while the latter does. I believe this is correct:

#[cfg(feature = "uuid-v1_0")]
impl Schema for uuid::Uuid {
    const SCHEMA: &'static NamedType = &NamedType {
        name: "Uuid",
        ty: <[u8; 16]>::SCHEMA.ty,
    };
}

[zeenix]

I will plan to merge this in a bit,

👍

but this impl is wrong, I believe. Uuid serializes to a [u8; 16], and a bytearray is basically a &[u8].

The bytearray is a misleading term then, so you can understand why I got confused. :) I'll update the patch. thanks.

[zeenix]

ut this impl is wrong, I believe. Uuid serializes to a [u8; 16], and a bytearray is basically a &[u8].

The bytearray is a misleading term then, so you can understand why I got confused. :) I'll update the patch. thanks.

Actually, it seems Uuid is serialized as a byte slice, so I think my impl is correct.

[jamesmunns]

Ahh, you're absolutely right - I saw that as_bytes() returns a [u8; 16], BUT they specifically call the serialize_bytes method, which turns it into a &[u8].

[jamesmunns]

Double confirming:

use uuid::Uuid;

fn main() {
    let val = Uuid::now_v7();
    let bytes = postcard::to_stdvec(&val).unwrap();
    assert_eq!(bytes.len(), 16);
}

// thread 'main' panicked at src/main.rs:6:5:
// assertion `left == right` failed
//   left: 17
//  right: 16
// note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Disappointing!

[zeenix]

Double confirming:

Thanks.

Disappointing!

Well, arrays are generally serialized as structs in serde and depending on the format, that could be much worse (besides it being very strange to encode a byte sequence as a struct). OTOH, if arrays were serialized as a sequence type, you'd still end up with the same length.

[jamesmunns]

In postcard at least, fixed sized arrays are serialized as essentially tuples, so [u8; 16] would be 16 bytes on the wire, while &[u8] where len == 16 would be 17 bytes on the wire.

I'm definitely less familiar with other serde formats would handle this tho!

[zeenix]

In postcard at least, fixed sized arrays are serialized as essentially tuples

I meant tuples, yeah. In the D-Bus format, they've the same encoding so I sometimes get them confused. :)

so [u8; 16] would be 16 bytes on the wire, while &[u8] where len == 16 would be 17 bytes on the wire.

That's saving one bytes but there is more processing and calls then because serde will call you encoder to serialize each byte separately. It could be that the compilers can optimize the 16 loops+calls but I wouldn't know about that.

Still, postcard could choose to serialize byte slice like a tuple, if it wanted since there are special Serializer and Deserializer method for this type.