Static requirements in `serialize_***_variant` methods

[MrGVSV]

I am trying to create a dynamic serializer for enum types and noticed that the Serializer::serialize_***_variant methods all require &'static str over just &str. Why is this? Could the static requirement be removed or are they needed for some purpose?

Variant Methods

https://github.com/serde-rs/serde/blob/819f90d9f692bcfdaa463233d5b5761e806b0870/serde/src/ser/mod.rs#L871-L876

https://github.com/serde-rs/serde/blob/819f90d9f692bcfdaa463233d5b5761e806b0870/serde/src/ser/mod.rs#L932-L940

https://github.com/serde-rs/serde/blob/819f90d9f692bcfdaa463233d5b5761e806b0870/serde/src/ser/mod.rs#L1116-L1122

https://github.com/serde-rs/serde/blob/819f90d9f692bcfdaa463233d5b5761e806b0870/serde/src/ser/mod.rs#L1243-L1249

For reference: These were added in fbad1940423489657d4d00134dd4de53408e251e as part of #437.

[edgarogh]

Why is this?

Probably because &'static str is Copy + Send + Sync + 'static and #[no_std]-compatible, which makes it much more convenient to work with. Removing it now would be a breaking change, and that's probably something that will never happen in the short term in serde.

But I don't understand your problem. If you're serializing enums, you already know all of their variants at compile time, no?

[MrGVSV]

Probably because &'static str is Copy + Send + Sync + 'static and #[no_std]-compatible, which makes it much more convenient to work with. Removing it now would be a breaking change, and that's probably something that will never happen in the short term in serde.

Yeah that makes sense, thank you!

But I don't understand your problem. If you're serializing enums, you already know all of their variants at compile time, no?

Sorry, I should have added more details in the description. This is for Bevy's reflection system. I wanted to allow for the serialization of DynamicEnum, which are structs that contain the information of an enum and implement an Enum trait.

Since a DynamicEnum isn't a physical type, and it can contain any kind of runtime data, we don't have access to &'static str (at least, not without interning, but I don't think we want/should go that route).

[edgarogh]

Ohh OK I see yeah. I sorta guessed this but the fact that you called this a dynamic enum type confused me (don't worry it's fine).

The default enum serializer methods (all these serialize_***_variant) may be too restrictive for what you want to do. That said, you can emulate an enum serializer with structs, like I showed here for an adjacently tagged enum (of course, you could adapt this to any representation). In this example, you'd replace u8 with the desired string type and you should be good.

Another very different idea, possibly a very bad one, but that could work in your situation, is to use a crate such as ustr that crates a global cache of interned strings. These strings are effectively leaked, that's the concept, but for this reason you can access them as a &'static str. This solution may work if your dynamic enums are meant to live for the program life and leaking their variant's name is not too much of an issue. The big advantage of a crate like this is that comparing UStrs is O(1) since two equal string will have the same memory address (and they're Copy + Send + Sync + 'static of course).

Ask me if you need more help, here I'm just leaving you with a few directions to look towards.