Robustness of this first difference function
Rustfmt is a tool for automatically formatting Rust code to the community-accepted style. Specifically, the { after the where should come on the next line.
Accept a &amp;[T] instead of a &amp;Vec&lt;T&gt;.




use std::ops::Sub;

fn first_difference&lt;T&gt;(input: &amp;[T]) -&gt; Vec&lt;T::Output&gt;
    where T: Sub&lt;Output = T&gt; + Clone
{
    let vec_len = input.len();

    input.iter()
        .take(vec_len - 1)
        .enumerate()
        .map(|(ind, val)| val.clone() - input[ind + 1].clone())
        .collect()
}

fn main() {
    println!("{:?}", first_difference(&amp;[1, 3, 1]));
}


However, this code will panic if presented with an empty input slice because it tries to subtract 1 from 0. This can be addressed by using some iterator adapters:

fn first_difference&lt;T&gt;(input: &amp;[T]) -&gt; Vec&lt;T::Output&gt;
    where T: Sub&lt;Output = T&gt; + Clone
{
    let a = input.iter();
    let b = input.iter().skip(1);

    a.zip(b).map(|(a, b)| a.clone() - b.clone()).collect()
}


The Clone requirement is a little sad to have. You could adjust the bounds to work directly on references. This uses higher-ranked trait bounds (for &lt;'a&gt;):

fn first_difference&lt;T&gt;(input: &amp;[T]) -&gt; Vec&lt;T&gt;
    where for &lt;'a&gt; &amp;'a T: Sub&lt;Output = T&gt;
{
    let a = input.iter();
    let b = input.iter().skip(1);

    a.zip(b).map(|(a, b)| a - b).collect()
}


I think the biggest "weakness" to the function is not one of its own. In Rust, subtraction may panic in certain cases. Specifically, when you exceed the range of the type, the compiler may abort the program. This can be controlled by the programmer, depending on the constraints of the problem at hand .




  Why doesn't the compiler complain about that lifetime specifier being
  undefined? The Rustonomicon says
  
  
    for&lt;'a&gt; can be read as "for all choices of 'a", and basically produces an infinite list of trait bounds that F must satisfy.
    Intense.
  
  
  which I agree is intense, but doesn't seem to tell me what the
  lifetime is. Is it the lifetime of F, or is it bounded in some other
  way externally?


for &lt;'a&gt; declares a new generic lifetime, that's why there's no compilation error. The quote from the Nomicon is fairly literal (as far as it can be) — the restriction in the where clause here is "any possible reference to a T needs to be able to be subtracted from another reference to a T. Those two references will share a unified lifetime 'a and the result of the subtraction will produce a T".

It's certainly a mouthful, but it's not impossible to understand once you've seen it a few times.

Specifically, the concrete lifetime will be the same as the incoming slice. This means I was probably being a over-clever, and the code could have been written as:

fn first_difference&lt;'a, T&gt;(input: &amp;'a [T]) -&gt; Vec&lt;T&gt;
    where &amp;'a T: Sub&lt;Output = T&gt;
{
    let a = input.iter();
    let b = input.iter().skip(1);

    a.zip(b).map(|(a, b)| a - b).collect()
}