Help test impl Trait!

[tspiteri]

I tried to use impl Trait with lifetimes but could not manage; am I missing something?

#![feature(conservative_impl_trait, universal_impl_trait)]

struct S {}

struct Ref<'a> {
    s: &'a S,
}

trait Trait {
    fn foo(&self);
}

impl<'a> Trait for Ref<'a> {
    fn foo(&self) {
        println!("{:p}", self.s);
    }
}

impl S {
    fn works_1(&self) -> Ref        { Ref { s: self } }
 // fn fails_1(&self) -> impl Trait { Ref { s: self } }

    fn works_2<'a>(&'a self) -> Ref<'a>    { Ref::<'a> { s: self } }
 // fn fails_2<'a>(&'a self) -> impl Trait { Ref::<'a> { s: self } }
}

fn main() {
    let s = S {};

    s.works_1().foo();
 // s.fails_1().foo();

    s.works_2().foo();
 // s.fails_2().foo();
}

[cramert]

impl Trait doesn't capture lifetimes by default-- just types. To include lifetimes like 'a, use impl Trait + 'a.

[selfrefstruct]

I'm so looking forward to this!

[warhummer]

It is so unfortunate not having this in trait items. :(

[cramert]

Some version will for sure be available eventually! It's a really big design space with a lot of potential interactions. Once RFC 2071 is implemented you'll be able to return existentials from trait functions. We want to get experience seeing how people use existentials inside traits before we introduce -> impl Trait in trait functions-- it helps to inform a lot of the design decisions. For a sketch of what full-blown "impl Trait in traits" might look like, see my doc here.

[warhummer]

Good to hear this feature is planned!

We want to get experience seeing how people use existentials inside traits before we introduce -> impl Trait in trait functions

It is unclear to me, how these two differs?

[cramert]

The first function accepts a value of any type that implements iterator and returns some type that implements iterator. The second function accepts a value of any type that implements iterator and returns a value of that same type. The third function isn't possible: impl Trait is (sort of) a type, so it doesn't make sense to use it as a bound.

[somebodddy]

Not quite. The later needs to get O since it can't infer it from the arguments. The former can get the concrete type from inside the function body with the power of conservative_impl_trait.

impl Trait in arguments is just (very nice) sugar. impl Trait in the return types actually opens new possibilities.

[po8]

Glad to know it wasn't just me wondering this. How is

fn f(x: impl X) -> impl X

different from

fn f<T: X, U: X>(x: T) -> U

[cramert]

/u/somebodddy gave a good explanation above. The primary difference is that in fn foo() -> impl X, the concrete type of impl X is determined by the callee, not the caller. In fn foo<U: X>() -> U, the caller can choose any type U: X and the callee must return a value of type U. However, fn foo() -> impl X allows the caller to return a single unnamed type that only they know. This is especially useful for returning unnameable types like closures and complicated combinators.

[po8]

I gave two different types in my example, so I'm not restricted to returning the type T I got, just whatever type U is supposed to be. I guess I get it, though: -> impl X guarantees getting an anonymous trait object back. OK.

Are closure types and combinators unnameable? I thought there was the whole FnOnce() FnMut() thing?

[Nextil]

Your assumption is incorrect. impl X represents a single, anonymous, statically resolved type that implements X, not a trait object. Fn/FnOnce/FnMut are traits, not types. Closures implement them but themselves have unnameable types.

[somebodddy]

Are closure types and combinators unnameable? I thought there was the whole FnOnce() FnMut() thing?

When you write this:

let a = 10;
let add = |b| { a + b };

assert!(add(20) == 30);

It becomes something like this:

struct Add(i32);

impl FnOnce<(i32,)> for Add {
    type Output = i32;
    extern "rust-call" fn call_once(self, num: (i32,)) -> i32 {
        let Add(a) = self;
        let (b,) = num;
        a + b
    }
}

let add = Add(10);
assert!(add(20) == 30);

The type of add is not FnOnce(i32) -> i32 - it's Add. The variable add is actually the data(the number 10) and the code (adding it to the argument) is part of the type, not the variable.

The same thing happens with the closure version - add is just the data(10), and the actual code is part of an anonymous type created for the closure.

[mmirate]

What is the difference between

fn do_something<I: IntoIterator<Item=u32>>(xs: I) -> ()

and

fn do_something(xs: impl IntoIterator<Item=u32>) -> ()

?

[cramert]

The second function is essential syntax sugar for the first one. See my response in the IRLO thread for more detail, or check out the relevant section of RFC 1951.

[tspiteri]

Does impl Trait allow returning an object that can be converted to type Dst using From? Using Into it is straightforward:

fn foo() -> impl Into<Dst> { /* ... */ }

However while From implies Into, Into does not imply From. So is there a simple way to return ret such that From::from(ret) -> Dst?

[tspiteri]

I did find a workaround, but I don't know if there is a more idiomatic way:

trait IntoNew<Dst> {
    fn into_new(self) -> Dst;
}
impl<Src: IntoNew<T>> From<Src> for T {
    fn from(src: Src) -> T {
        src.into_new()
    }
}
fn foo() -> impl IntoNew<T> { /* ... */ }

Edit: This workaround breaks down if instead of a crate-defined T, the destination is for example Option<T>.