VecSkipError fails on tagged enum

[wmte]

I have the following example;

struct RGB { r: u8, g: u8, b: u8 }

enum Pixel {
    RGB(RGB),
    Grey(u8),
}

struct Picture { pixels: Vec<Pixel> }

impl<'de> serde::Deserialize for Picture {
    fn deserialize<D>(deser: D) -> Result<Self, D::Error> where D: serde::Deserializer<'de> {
        
        // this works
        let pixels: Vec<Pixel> = serde::Deserialize::deserialize(deser)?;
        
        // this fails with 'expected "string or map", found: "a sequence"'
        let pixels: Vec<Pixel> = serde_with::VecSkipError::<serde_with::Same>::deserialize_as(deser)?;
        
        Ok(Self { pixels })
    }
}

I have tracked the issue down to this match. At which point, the value of err reads 'expected "string or map", found "a sequence"'.

My tagged enum is getting serialized as a Seq. It appears that the inner content deserializer doesn't expect nested sequences? I'm not sure how to continue investigating, but deserializing straight to Vec works fine with normal Serde, I would expect VecSkipError to just drop in. I cannot use the derives because my types have other constraints.

Thanks!

[jonasbb]

VecSkipError is not a drop-in replacement as it suffers from serde-rs/serde#1183
To continue after a deserialization error, you need to buffer the data, to ensure the Deserializer is always in a good state.

Can you please provide more details for your bug report? Without knowing how your serialized data looks and what data format you are using, there isn't anything actionable for me to do here.

[wmte]

Thanks for responding so quickly.

For some reason my struct RGB is being serialized as a Seq of 3 u8s. I am using normal serde on the serialize side, and deserialize_as is expecting a Map. Do I need to also use serialize_as in some way for round trip compatibility?

My serialize function;

fn serialize<S>(&self, ser: S) -> Result<S::Ok, S::Error> where S: serde::Serializer {
	self.pixels.serialize(ser)
}

I'm using RON, and my data appears as;

pixels:[(RGB((r:10,g:10,b:10))),(RGB((r:20,g:20,b:20)))]

I believe the issue is the inner parenthesis around the integers. I'm not completely clear on why deser thinks (r:10,g:10,b:10) is a Seq, as in RON this is struct notation.

[jonasbb]

RON is a complicated format. Its data format is more complicated than what can be modelled well with the serde API. This means it needs to have the context of the Rust types for proper deserialization. Any buffering will cause problems, for example ron-rs/ron#500. Maybe the v0.9 design of RON will help a bit.
I'm sorry I can't be of more help here.