The compiler is confused because it does not know which provenance and lifetime to assign to the returned references. We as programmers can see that the return value depends on both input references, so we can help Rust by providing lifetime hints.\footnote{Actually, the compiler could infer these lifetimes but it would rely on global program analysis to do so. It is also possible to infer function types, but Rust chose to always be explicit about the types and lifetimes you use and have them be explicit parts of the API of a function.}
\begin{lstlisting}[language=Rust, caption={Iterator over two slices}, label={lst:two-refs}]
\begin{lstlisting}[language=Rust, caption={Iterator over two slices}, label={lst:lifetime-parameters}]
fn both<'a>(first: &'a [i32], second: &'a [i32])
-> impl Iterator<Item=&'a i32>
{
...
...
@@ -383,7 +383,7 @@ if xref != &0 {
x = 42;
\end{lstlisting}
Now the \ac{CFG} splits up to accomodate both possible paths the program could take during execution. At the \inline{if}, the graph splits into two, but in the last node, both paths join up again. Here we can see that in the \inline{false} branch no problem occurs, but in the \inline{true} branch we try to modify \inline{x} even though \inline{xref} is used later in the same path. Modifying \inline{x} on the last line is okay, though.
Now the \ac{CFG}(\autoref{fig:cfg-non-lexical-lifetimes-branch}) splits up to accomodate both possible paths the program could take during execution. At the \inline{if}, the graph splits into two, but in the last node, both paths join up again. Here we can see that in the \inline{false} branch no problem occurs, but in the \inline{true} branch we try to modify \inline{x} even though \inline{xref} is used later in the same path. Modifying \inline{x} on the last line is okay, though.
