use serde::ser::{Serialize, Serializer, SerializeTuple};
 
trait SerializeTuple {
    type Ok;
    type Error;
    
    fn serialize_element<T: ?Sized + Serialize>(&mut self, value: &T) -> Result<(), Self::Error>;
    fn end(self) -> Result<Self::Ok, Self::Error>;
}

use serde::{Serialize, Serializer};
use serde::ser::{SerializeSeq, SerializeTuple};
 
fn tuple_vs_sequence() {
    // Tuple: fixed arity known at compile time
    let tuple: (i32, i32, i32) = (1, 2, 3);
    
    // The type (i32, i32, i32) tells us: exactly 3 elements
    // No length prefix needed in serialization
    
    // Sequence: variable length known at runtime
    let vec: Vec<i32> = vec
![1, 2, 3];
    
    // The type Vec<i32> tells us: some number of i32s
    // Length must be serialized as prefix so deserializer knows when to stop
}
 
fn serialize_tuple<S: Serializer>(tuple: &(i32, String, bool), serializer: S) -> Result<S::Ok, S::Error> {
    // Tuple serialization
    let mut t = serializer.serialize_tuple(3)?;  // Length hint provided
    t.serialize_element(&tuple.0)?;
    t.serialize_element(&tuple.1)?;
    t.serialize_element(&tuple.2)?;
    t.end()
}
 
fn serialize_vec<S: Serializer>(vec: &Vec<i32>, serializer: S) -> Result<S::Ok, S::Error> {
    // Sequence serialization
    let mut seq = serializer.serialize_seq(Some(vec.len()))?;
    for element in vec {
        seq.serialize_element(element)?;
    }
    seq.end()
}

use serde::{Serialize, Serializer};
use serde::ser::SerializeTuple;
 
impl Serialize for MyTuple {
    fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
    where
        S: Serializer,
    {
        // serialize_tuple takes a length hint
        // But the hint is for the serializer's convenience
        // The actual element count is known from the type
        let mut tup = serializer.serialize_tuple(2)?;
        
        // serialize_element adds one element at a time
        tup.serialize_element(&self.field1)?;
        tup.serialize_element(&self.field2)?;
        
        // end completes the tuple
        tup.end()
    }
}
 
struct MyTuple {
    field1: i32,
    field2: String,
}

use serde::{Serialize, Deserialize};
 
fn json_output_comparison() {
    // Tuple serialization in JSON
    let tuple: (i32, i32, i32) = (1, 2, 3);
    let json = serde_json::to_string(&tuple).unwrap();
    // Output: [1,2,3]
    // No length prefix - just the elements
    
    // Sequence serialization in JSON
    let vec: Vec<i32> = vec
![1, 2, 3];
    let json = serde_json::to_string(&vec).unwrap();
    // Output: [1,2,3]
    // In JSON, both look the same
    // But in binary formats, the difference matters
    
    // In a binary format like bincode:
    // Tuple: elements written directly
    // Sequence: [length][elements...]
}

use serde::{Serialize, Deserialize};
 
// In a binary format like bincode or MessagePack:
 
// Tuple (i32, i32, i32) serializes as:
// [4 bytes for first i32][4 bytes for second i32][4 bytes for third i32]
// Total: 12 bytes (assuming 4-byte i32)
// No length prefix because deserializer knows to expect 3 elements
 
// Vec<i32> serializes as:
// [length as u64][elements...]
// Total: 8 bytes (length) + 12 bytes (elements) = 20 bytes
// Length prefix so deserializer knows when to stop
 
fn binary_comparison() {
    // The tuple format is more compact
    // And deserialization doesn't need to read a length prefix
    
    // For (i32, i32, i32):
    // Deserializer reads type signature: "this is a tuple of 3 i32s"
    // Then reads exactly 3 i32s
    
    // For Vec<i32>:
    // Deserializer reads type signature: "this is a sequence of i32s"
    // Then reads length (how many?)
    // Then reads that many i32s
}

use serde::ser::{Serializer, SerializeTuple};
 
fn length_hint_purpose() {
    // serialize_tuple takes a length parameter
    // fn serialize_tuple(self, len: usize) -> Result<Self::SerializeTuple, Self::Error>;
    
    // Why provide length if it's not used as prefix?
    
    // 1. Some formats can pre-allocate buffers
    //    Knowing size helps optimize allocation
    
    // 2. Some formats verify consistency
    //    Check that serialize_element is called correct number of times
    
    // 3. Human-readable formats might use it for formatting
    //    JSON: might format multi-element tuples differently
    
    // 4. Some formats encode the length anyway (redundant but valid)
    //    The serializer is allowed to write a length prefix
    //    But deserializer must not require it
    
    // The key: length hint is for serializer optimization
    // The deserializer uses type info, not serialized length
}

use serde::ser::{Serializer, SerializeTuple, Ok, Error};
use std::io::Write;
 
struct MySerializer<'a> {
    output: &'a mut Vec<u8>,
}
 
impl<'a> Serializer for MySerializer<'a> {
    type Ok = ();
    type Error = MyError;
    type SerializeTuple = TupleSerializer<'a>;
    
    fn serialize_tuple(self, len: usize) -> Result<Self::SerializeTuple, Self::Error> {
        // len is provided but we don't write it
        // We'll use it for validation or optimization
        Ok(TupleSerializer {
            output: self.output,
            expected: len,
            written: 0,
        })
    }
    
    // ... other methods
}
 
struct TupleSerializer<'a> {
    output: &'a mut Vec<u8>,
    expected: usize,
    written: usize,
}
 
impl<'a> SerializeTuple for TupleSerializer<'a> {
    type Ok = ();
    type Error = MyError;
    
    fn serialize_element<T: ?Sized + Serialize>(&mut self, value: &T) -> Result<(), Self::Error> {
        // Write the element directly, no length prefix
        // The actual serialization of T happens here
        value.serialize(&mut MySerializer { output: self.output })?;
        self.written += 1;
        Ok(())
    }
    
    fn end(self) -> Result<Self::Ok, Self::Error> {
        // Verify we wrote the expected number of elements
        if self.written != self.expected {
            return Err(MyError::LengthMismatch);
        }
        Ok(())
    }
}
 
#[derive(Debug)]
enum MyError {
    LengthMismatch,
}
 
impl serde::ser::Error for MyError {
    fn custom<T: std::fmt::Display>(_msg: T) -> Self { todo!() }
}
 
impl std::fmt::Display for MyError {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { todo!() }
}
 
impl std::error::Error for MyError {}
 
use serde::Serialize;

use serde::de::{Deserializer, SeqAccess, Visitor};
 
fn tuple_deserialization() {
    // Deserializing a tuple doesn't read a length prefix
    // The type tells the deserializer what to expect
    
    // For (i32, String, bool):
    // 1. Deserializer knows to expect exactly 3 elements
    // 2. Read first element as i32
    // 3. Read second element as String
    // 4. Read third element as bool
    // 5. Done - no length to check
    
    // For Vec<i32>:
    // 1. Deserializer sees sequence type
    // 2. Read length (from serialized data)
    // 3. Read 'length' many i32 elements
    
    // The deserialize_tuple method receives the expected length:
    // fn deserialize_tuple<V: Visitor>(
    //     self,
    //     len: usize,        // Expected length from type
    //     visitor: V,
    // ) -> Result<V::Value, Self::Error>;
    
    // The len comes from the type, not from serialized data
}

use serde::{Serialize, Serializer};
use serde::ser::SerializeTupleStruct;
 
#[derive(Serialize)]
struct Point {
    x: i32,
    y: i32,
}
 
fn tuple_struct_example() {
    // SerializeTupleStruct is similar to SerializeTuple
    // Used for structs serialized as tuples (tuple structs or with #[serde(transparent)])
    
    // A tuple struct like struct Point(i32, i32):
    // Also has fixed arity (2 elements)
    // Also serialized without length prefix
    
    // #[derive(Serialize)] generates:
    impl Serialize for Point {
        fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
        where
            S: Serializer,
        {
            let mut s = serializer.serialize_tuple_struct("Point", 2)?;
            s.serialize_field(&self.x)?;
            s.serialize_field(&self.y)?;
            s.end()
        }
    }
    
    // serialize_tuple_struct also takes a name and length
    // But the length is not serialized in most formats
}

use serde::{Serialize, Deserialize};
 
fn format_differences() {
    // Most formats: no length prefix for tuples
    
    // JSON: arrays, no length prefix
    // (1, 2, 3) -> [1,2,3]
    
    // Bincode: no length prefix
    // (1u32, 2u32, 3u32) -> [4 bytes][4 bytes][4 bytes]
    
    // MessagePack: depends on format variant
    // Fixed arrays for small tuples
    
    // Some formats might write length:
    // This is allowed but unusual
    // The format must handle both tuples and sequences
    
    // A format that writes length for tuples:
    // Must still deserialize tuples using type info
    // Can't require reading length from data
}

use serde::{Serialize, Serializer};
 
fn unit_type() {
    // The unit type () is a zero-length tuple
    // serialize_tuple(0) with no elements
    
    impl Serialize for () {
        fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
        where
            S: Serializer,
        {
            serializer.serialize_unit()
            // Or equivalently: serializer.serialize_tuple(0)?.end()
        }
    }
    
    // Zero elements = no serialization output for many formats
    // In JSON: () -> null
    // In bincode: () -> (empty)
}

use serde::{Serialize, Serializer};
 
fn single_element_tuple() {
    // (T,) is a one-element tuple
    // serialize_tuple(1) with one element
    
    let single: (i32,) = (42,);
    
    // Serialization:
    // let mut t = serializer.serialize_tuple(1)?;
    // t.serialize_element(&single.0)?;
    // t.end()
    
    // Most formats serialize this the same as T
    // But type-level distinction is preserved
    
    // In JSON: (42,) -> [42]
    // An array with one element
}

use serde::{Serialize, Deserialize};
 
fn performance() {
    // Tuple serialization advantages:
    
    // 1. No length prefix to write
    //    Saves a few bytes (typically 1-8 depending on format)
    
    // 2. No length prefix to read and validate
    //    Deserialization is slightly faster
    
    // 3. Fixed memory allocation possible
    //    Deserializer can allocate exact size upfront
    
    // 4. Type-level verification
    //    Mismatch between expected and actual length is type error
    
    // For sequences:
    // - Must write length (or sentinel value)
    // - Must read and validate length
    // - Must handle potentially very large lengths
    
    // For tuples:
    // - Length known at compile time
    // - No runtime length validation needed
    // - Smaller serialized size (for binary formats)
}

use serde::{Serialize, Serializer};
 
fn common_sizes() {
    // serde has specific methods for common tuple sizes
    
    // 0-tuple: ()
    serializer.serialize_unit();
    
    // 1-tuple: (T,)
    // Uses serialize_tuple(1)
    
    // 2-tuple: (T, U)
    // Uses serialize_tuple(2)
    
    // ... up to typically 16 elements
    
    // For tuples larger than the built-in support:
    // Still uses serialize_tuple, just with higher len
    // The trait implementations are generated by macros
    
    // serialize_tuple(len) works for any len
    // The serializer might optimize for small sizes
}

use serde::ser::{Serializer, SerializeSeq, SerializeTuple};
 
fn seq_vs_tuple_comparison() {
    // SerializeSeq: variable-length sequences
    // - serialize_seq(Some(len)) starts sequence
    // - serialize_element for each element
    // - end() finishes
    // - Length IS serialized (or sentinels used)
    
    // SerializeTuple: fixed-length tuples
    // - serialize_tuple(len) starts tuple
    // - serialize_element for each element
    // - end() finishes
    // - Length is NOT serialized (in most formats)
    
    // The interfaces are similar but semantics differ:
    
    // Sequence:
    // - Length unknown at compile time
    // - Must communicate length to deserializer
    // - Used for Vec, slice, arrays with dynamic length
    
    // Tuple:
    // - Length known at compile time
    // - Deserializer uses type info for length
    // - Used for tuples, tuple structs
}

use serde::{Serialize, Serializer, Deserialize, Deserializer};
use serde::ser::SerializeTuple;
use serde::de::{Visitor, SeqAccess};
 
struct Pair<T, U>(T, U);
 
impl<T: Serialize, U: Serialize> Serialize for Pair<T, U> {
    fn serialize<S>(&self, serializer: S) -> Result<S::Ok, S::Error>
    where
        S: Serializer,
    {
        // Serialize as a 2-element tuple
        let mut tup = serializer.serialize_tuple(2)?;
        tup.serialize_element(&self.0)?;
        tup.serialize_element(&self.1)?;
        tup.end()
    }
}
 
impl<'de, T: Deserialize<'de>, U: Deserialize<'de>> Deserialize<'de> for Pair<T, U> {
    fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
    where
        D: Deserializer<'de>,
    {
        struct PairVisitor<T, U>(std::marker::PhantomData<(T, U)>);
        
        impl<'de, T: Deserialize<'de>, U: Deserialize<'de>> Visitor<'de> for PairVisitor<T, U> {
            type Value = Pair<T, U>;
            
            fn visit_seq<V>(self, mut seq: V) -> Result<Pair<T, U>, V::Error>
            where
                V: SeqAccess<'de>,
            {
                let first: T = seq.next_element()?
                    .ok_or_else(|| serde::de::Error::invalid_length(0, &self))?;
                let second: U = seq.next_element()?
                    .ok_or_else(|| serde::de::Error::invalid_length(1, &self))?;
                Ok(Pair(first, second))
            }
        }
        
        deserializer.deserialize_tuple(2, PairVisitor(std::marker::PhantomData))
    }
}

// serialize_element adds one element to the tuple serialization
// It's called once per element, in order
 
// For a tuple (A, B, C):
// let mut tup = serializer.serialize_tuple(3)?;
// tup.serialize_element(&a)?;  // First element
// tup.serialize_element(&b)?;  // Second element
// tup.serialize_element(&c)?;  // Third element
// tup.end()?;

// The type (A, B, C) encodes:
// - It's a tuple
// - It has exactly 3 elements
// - Element types are A, B, C
 
// The serializer uses type info to know:
// - How many elements to write
// - How many elements to read back
 
// No need to serialize the count "3"
// The deserializer knows from the type signature

// Sequences (Vec<T>, &[T]):
// - serialize_seq(Some(len))
// - Length must be serialized
// - Deserializer reads length to know when to stop
 
// Tuples ((A, B, C)):
// - serialize_tuple(len)
// - Length is NOT serialized (usually)
// - Deserializer uses type info to know when to stop