cases to potentially consider for lifetime elision rules.

lt_elision.rs

#![allow(non_camel_case_types)]
#![allow(dead_code)]

struct S_sans_LT     { x: int }
struct S_avec_LT<'a> { x: int, y: &'a int }

trait T_sans_LT_erroneous {
    // (No lifetimes introduced by trait, so these methods should be
    // straight-forward applications of the documented elision rules)

    fn m1(self) -> &int;    // ==> this is an error
}

trait T_sans_LT  {
    // (No lifetimes introduced by trait, so these methods should be
    // straight-forward applications of the documented elision rules)
    
    fn m2(&self) -> &int;   // ==> `fn m2<'fresh>(&'fresh self) m-> 'fresh int;`
}

trait T_avec_LT<'b> {
    // The lifetime elision rules presumably apply to these trait
    // method definitions; but then, is the `'b` on the trait
    // considered an input position ... ?

    fn m3(self) -> &int;     // ... might infer `&'b int` here, not error ...

    fn m4(&self) -> &int;    // ... while rule 3 ==> `&'fresh int` here ...

    fn m5(&'b self) -> &int; // ... and rule 3 ==> `&'b int` here.
}


impl<'c> S_sans_LT {
    // is the `impl<..>` an input position for the purposes of the
    // method definitions below?  (probably not, since this header
    // is pretty nonsensical, but I had to ask -- note that rustc
    // currently accepts such a header) ...

    fn m6(self) -> &int     // it changes whether this is an error.
        { unimplemented!() }
    fn m7(&self) -> &int    // Rule 3 still applies, as in `m2` and `m4` above.
        { unimplemented!() }
}

impl<'d> S_avec_LT<'d> {
    // Even if `impl<..>` is not an input lifetime position, is the S_avec_LT<'d>
    // providing an input lifetime position for hte method definitions below?
    // This strikes me as more plausible, though rarely useful...

    fn m8(self) -> &int     // changes whether this is an error, or `&'d int`.
        { unimplemented!() }

    fn m9(&self) -> &int    // Presumably even here Rule 3 still applies.
        { unimplemented!() }
}

// The answers to most of the questions below can probably be
// reasonably inferred given the answers to the questions above.

impl<'e> T_avec_LT<'e> for S_avec_LT<'e> {
    fn m3(self) -> &int
        // is `&'e int` inferred here?  Or are there zero input positions?
    { unimplemented!() }

    fn m4(&self) -> &int
        // Rule 3 ==> the fresh lifetime for &self applies to output, yes?
    { unimplemented!() }

    fn m5(&'e self) -> &int
        // again by Rule 3, 'e is applied to the output position.
    { unimplemented!() }
}

impl<'f> T_avec_LT<'f> for S_sans_LT {
    fn m3(self) -> &int
        // is `&'f int` inferred here?  Or are there zero input positions?
    { unimplemented!() }

    fn m4(&self) -> &int
        // Rule 3 ==> the fresh lifetime for &self applies to output, yes?
    { unimplemented!() }

    fn m5(&'f self) -> &int
        // again by Rule 3, 'f is applied to the output position.
    { unimplemented!() }
}

impl<'g> T_sans_LT for S_avec_LT<'g> {
    fn m2(&self) -> &int
        // rule 3 ==> the fresh lifetime for &self applies to output, yes?
    { unimplemented!() }
}

impl<'h> T_sans_LT for S_sans_LT {
    fn m2(&self) -> &int
        // rule 3 ==> the fresh lifetime for &self applies to output, yes?
    { unimplemented!() }
}

fn main() {
    let i = 0i;
    let a_avec_lt = S_avec_LT { x: 1, y: &i };
    let b_sans_lt = S_sans_LT { x: 3 };

    let a1 = a_avec_lt.m1();
    let a2 = a_avec_lt.m2();
    let a3 = a_avec_lt.m3();
    let a4 = a_avec_lt.m4();

    let b1 = b_sans_lt.m1();
    let b2 = b_sans_lt.m2();
    let b3 = b_sans_lt.m3();
    let b4 = b_sans_lt.m4();
    let _ = (a1,a2,a3,a4, b1,b2,b3,b4);
    println!("Hello World");
}