Idioms for DRY code inside trait implementations (rustlings example)

Question

I am currently making my way through the Rust book and rustlings. try_from_into.rs asks us to implement TryFrom for a tuple, and array, and a slice. The array and slice versions fit nicely into an iter/map/collect pattern, e.g. as follows:

// Array implementation
impl TryFrom<[i16; 3]> for Color {
    type Error = IntoColorError;
    fn try_from(arr: [i16; 3]) -> Result<Self, Self::Error> {
        match arr
            .iter()
            .map(|x| u8::try_from(*x))
            .collect::<Result<Vec<_>, _>>()
        {
            Ok(v) => Ok(Color {
                red: v[0],
                green: v[1],
                blue: v[2],
            }),
            _ => Err(IntoColorError::IntConversion),
        }
    }
}

^Playground

Possibly this is not idiomatic either, so I'd appreciate any corrections.

However, the tuple implementation seems to leave me with two choices:

1. Put the tuple (of 3 i16s) into an array and then use the map pattern above. This seems wasteful.

2. Repeat myself by converting each value to u8, checking the result, and assigning to a local variable, e.g.

   fn try_from(tuple: (i16, i16, i16)) -> Result<Self, Self::Error> {
       let red = match u8::try_from(val) {
           Ok(v) => Ok(v),
           _ => return Err(IntoColorError::IntConversion),
       };
       let green = ...
       let blue = ...
       Ok(Color { red, green, blue })
   }
   

My first instinct is to put the match code into a helper and inline it if the language supported doing so, but Rust seems to have some barriers to that:

• Private trait methods are not allowed, so I can't just add a helper inside the implementation. However, I lose any notion of what Self::Error is outside of the implementation.
• We can't use generic parameters from outer functions, so neither can I create an inner function which uses Self::Error in the try_from definition, e.g. like

  fn try_from(tuple: (i16, i16, i16)) -> Result<Self, Self::Error> {
      #[inline]
      fn i16_to_u8(val: i16) -> Result<u8, Self::Error> {
          match u8::try_from(val) {
              Ok(v) => Ok(v),
              _ => return Err(IntoColorError::IntConversion),
          }
      }
  
      let red = i16_to_u8(tuple.0)?;
      ...
  }
  

What are the Rust idioms for avoiding repeated code inside trait implementations, especially where a helper method seems like the obvious choice to someone coming from languages where these are commonplace?

Answer 1

You could change the match block to a ? if you map the error into an IntoColorError. That will allow you to continue chaining methods so you can call try_into() to convert the Vec<u8> into [u8; 3], which can in turn be destructured into separate red, green, and blue variables.

impl TryFrom<[i16; 3]> for Color {
    type Error = IntoColorError;
    fn try_from(arr: [i16; 3]) -> Result<Self, Self::Error> {
        let [red, green, blue]: [u8; 3] = arr
            .iter()
            .map(|x| u8::try_from(*x))
            .collect::<Result<Vec<_>, _>>()
            .map_err(|_| IntoColorError::IntConversion)?
            .try_into()
            .unwrap();
        Ok(Color{ red, green, blue })
    }
}

I'd probably break that up into two or three separate statements myself, but you get the idea.

If you apply the same error mapping idea to the tuple case you can get it fairly compact. It's still repetitive but the repetition isn't too bad thanks to ?:

impl TryFrom<(i16, i16, i16)> for Color {
    type Error = IntoColorError;
    fn try_from(tuple: (i16, i16, i16)) -> Result<Self, Self::Error> {
        let (red, green, blue) = tuple;
        let red: u8 = red.try_into().map_err(|_| IntoColorError::IntConversion)?;
        let green: u8 = green.try_into().map_err(|_| IntoColorError::IntConversion)?;
        let blue: u8 = blue.try_into().map_err(|_| IntoColorError::IntConversion)?;
        Ok(Color{ red, green, blue })
    }
}

You can see both implementations on the Playground.

It is possible to eliminate the repetitive map_err calls. If you're on nightly then you could use a try block to capture the TryFromIntErrors and convert them to IntoColorErrors.

#![feature(try_blocks)]

impl TryFrom<(i16, i16, i16)> for Color {
    type Error = IntoColorError;
    fn try_from(tuple: (i16, i16, i16)) -> Result<Self, Self::Error> {
        let result: Result<_, TryFromIntError> = try {
            let (red, green, blue) = tuple;
            let red: u8 = red.try_into()?;
            let green: u8 = green.try_into()?;
            let blue: u8 = blue.try_into()?;
            Color{ red, green, blue }
        };
        result.map_err(|_| IntoColorError::IntConversion)
    }
}

^Playground

On stable you could achieve the same effect with an immediately-invoked function expression, or IIFE:

impl TryFrom<(i16, i16, i16)> for Color {
    type Error = IntoColorError;
    fn try_from(tuple: (i16, i16, i16)) -> Result<Self, Self::Error> {
        (|| {
            let (red, green, blue) = tuple;
            let red: u8 = red.try_into()?;
            let green: u8 = green.try_into()?;
            let blue: u8 = blue.try_into()?;
            Ok(Color{ red, green, blue })
        })()
        .map_err(|_: TryFromIntError| IntoColorError::IntConversion)
    }
}

^Playground

---

What are the Rust idioms for avoiding repeated code inside trait implementations, especially where a helper method seems like the obvious choice to someone coming from languages where these are commonplace?

Free functions. You can make helper methods outside the impl block.

Answer 2

You seem to have a little bit of a misconception of how associated types in traits work, because

However, I lose any notion of what Self::Error is outside of the implementation.

is not strictly true. When you leave the trait's impl block, you don't lose the notion of Self::Error, you lose the notion of Self. You can create a helper function outside the the impl that refers to the type:

fn i16_to_u8(n:i16) -> Result<u8, <Color as TryFrom<(i16,i16,i16)>>::Error>{
    n.try_into().map_err(|_| IntoColorError::IntConversion)
}

You can also make an associated function in a separate impl block for Color:

impl Color{
    fn i16_to_u8(n:i16) -> Result<u8, <Self as TryFrom<(i16,i16,i16)>>::Error>{
        n.try_into().map_err(|_| IntoColorError::IntConversion)
    }
}

The associated type for a trait exists in all scopes the trait is in. In many cases, you do need the fully qualified syntax, <Type as Trait>::Name so the compiler knows which implementation's type to use (this occurs for TryFrom because of a blanket impl over From).

You can also manually desugar the type alias yourself, but it does reduce maintainability:

fn i16_to_u8(n:i16) -> Result<u8, IntoColorError>{
    n.try_into().map_err(|_| IntoColorError::IntConversion)
}