Feat/UUID

[Roms1383]

In the same fashion, this PR adds support for uuid crate, since it's widely used in app and web alike. I'm gonna keep as Draft until it's implemented downstream on flutter_rust_bridge (please hold on for a while, previous PR for chrono types is almost finished but not quite yet).

[Roms1383]

Leaving link to experiment in the playground as a reminder, mostly to myself ^^

[Roms1383]

Also, something I'm not familiar in FFI / Rust / Dart contexts is if endianness matters or if this is already taken care of. So, should I explicitly settle on little or big endian, and if yes, which one would you recommend ?

[Roms1383]

What is interesting is that we can also "pack" a Vec<uuid::Uuid> into a single Vec<u8> and be able to reconstruct it on both sides :

• Rust, with another little experiment on the playground.
• Dart, presumably by splitting the Uint8List into chunks. Dart, presumably by leveraging offset parameter in UuidValue.fromByteList. (update: offset can be used in UuidValue.fromByteList, but the buffer has to be of length 16)

[Roms1383]

Also, something I'm not familiar in FFI / Rust / Dart contexts is if endianness matters or if this is already taken care of. So, should I explicitly settle on little or big endian, and if yes, which one would you recommend ?

I could also adjust to the system, using Endianness on Dart side and cpu_endian on Rust side, what do you think ?

[shekohex]

Also, something I'm not familiar in FFI / Rust / Dart contexts is if endianness matters or if this is already taken care of. So, should I explicitly settle on little or big endian, and if yes, which one would you recommend ?

I could also adjust to the system, using Endianness on Dart side and cpu_endian on Rust side, what do you think ?

I do think it does not matter that much, you better stick with just one on both sides, the other option is use the native endianness (in rust you use *_to_ne_bytes() for example). Nonetheless, you will declare it in the docs and with an example too.

[Roms1383]

I do think it does not matter that much, you better stick with just one on both sides, the other option is use the native endianness (in rust you use *_to_ne_bytes() for example). Nonetheless, you will declare it in the docs and with an example too.

I made a quick bench locally to check whether there's a big delta in performance when using native endianness and it doesn't seem to make any notable difference (~2%). I cannot test on different machines with different endianness so I guess you're right, it can probably be ignored.

[Roms1383]

I think it's ready for review 👌

[shekohex]

There will be a bit of delay to publish this version now on crates.io since I'm on Mobile right now, but once I've my laptop I will issue a new release.

Thank you!

[Roms1383]

Thanks Shady, no worries ! We're almost good downstream too ^^