With serde, is it possible to get unknown variant names outside of a deserializing error?

[Dekkonot]

I'm using serde to deserialize a file format that looks something like this:

<root>
  <list>
     <type1>content</type1>
     <type2>a new and exciting content type </type2>
     <!-- etc -->
  </list>
</root>

This is easy to implement and I've done so using an enum because I know all the types that currently exist under list. However, I'm not in control of the file format so at any point in the future new variants to to that enum might be added without me supporting them. I'd like to not fail in this case, so using #[serde(other)] on a variant is the obvious solution.

This however means that I'm silently skipped over unknown data. I'd prefer to emit a warning to the user in this case simply because it's bad UX. While that's (again) easy to do, I would also like to include the type of the new data if at all possible so that people reporting it know what to tell me. However, it seems like there's no way to get this information outside of the error raised when parsing an unknown variant.

I realize this might be a limitation with Serde but I may also be missing something so I though I'd ask directly. Is there a way to get the variant name of an unknown enum without the error that's returned when failing to parse it?

[Mingun]

This is a serde limitation, tracked in serde-rs/serde#912, it is just the derive macro does not yet support. The other relevant serde issues:

• accept #[serde(other)] on non-unit enum variants serde-rs/serde#1973
• #[serde(other)] and externally tagged enum serde-rs/serde#2010
• Give #[serde(other)] functionality in externally tagged enums and on newtype variants serde-rs/serde#2365
• Be able to access the value of the tag in a tagged enum variant serde-rs/serde#2455

If you find a workaround, we can add it to the documentation. Feel free to open PR for that, like #601

[Dekkonot]

A quick followup: Is it possible to catch the name of an element using Serde? I know it's not generally used for deserializing but since it exists, is it exposed anywhere?

[Mingun]

Yes, that is possible. MapAccess::next_key() will deserialize from element of <ns:element>.