feat: opt-in serialization of sequences as sets

[neoeinstein]

I ran into a use case where I'd like to be able to serialize a set of values ergonomically. This relies on the with functionality from serde to make it completely opt in, enabling this use case without affecting any existing serialization or deserialization.

[neoeinstein]

Before this merges, I do have a method that may allow this to compile down to zero-cost after monomorphization. I'm also considering the value splitting this into 3 modules instead having just one for all three set types and inferring from the first item. Any thoughts?

[bryanburgers]

This is awesome. Thank you!

[bryanburgers]

I feel like

#[serde(with = "serde_dynamo::byte_set")]
#[serde(with = "serde_dynamo::number_set")]
#[serde(with = "serde_dynamo::string_set")]

feels a bit better.

[neoeinstein]

I can made that change; this was mainly just for organization and avoiding a bunch of modules at the crate base. I've been using bytes set (with the plural) since it's a set of byte arrays. If that's okay, I can rename and move these modules into the crate root.

[bryanburgers]

I've been going off of the naming described here where they're called "number set", "string set" and "binary set".

[bryanburgers]

For what it's worth, I did once have an implementation of this, but the key bit that was clunky was telling the Serializer that the next stuff is a set.

I looked deeply at std::any::Any and asked the rust core team about it because it doesn't quite work.

I also had something with thread locals that was kinda gross.

Your newtype struct thing makes a ton of sense and I like it.

In the mean time, I noticed that std::any::Provider now exists, which solves my original problem and doesn't require magic strings, so I wrote up a PR to serde to use it: serde-rs/serde#2420

That doesn't preclude this from merging for two reasons:

• std::any::Provider is still nightly only
• I have no idea if the serde team is interested in that direction.

[neoeinstein]

Pull request has been updated to address the above comments on module naming.

[bryanburgers]

@neoeinstein I have no concerns right now. I just need to find the time to dig in and hopefully merge. Thanks for your contribution!

[bryanburgers]

Released in 4.2.0, which is now up on crates.io. Thank you!