Self-defined callback?

[dakom]

So I have something kinda like this:

struct Foo<F: Fn()> {
    pub cb: F   
}

impl <F: Fn()> Foo <F> {
    pub fn new() -> Self {
        Self {
            cb: || {}
        }
    }
}

That doesn't work... but is there any way to do something like this without boxing / trait objects?

[OptimisticPeach]

Well, it's complicated...

You generally can't name most types that implement the Fn* traits, so in general you can't do this (and putting a type parameter which is constrained on one of those traits is therefore I'll advised). There are, however, two types which you can name: fn() and Box<dyn Fn()>, the latter of which you've already decided against. The former seems like the better option, however it has some downsides too:

• You can't capture anything in the closure.
• You miss out on function inlining as is done when the type is a definite function (look up function items vs function pointers).

[steffahn]

You can do something like

struct Foo<F: Fn()> {
    pub cb: F,
}

impl<F: Fn()> Foo<F> {
    pub fn new() -> Foo<impl Fn()> {
        Foo { cb: || {} }
    }
}

It’s “cheating” a bit, since this adds a new method to all possible Fn<F> types while only returning a particular Foo<{type of the “|| {}” closure}> type.

I’m guessing that your working on some actual use case and that use-case might require multiple Foo structs with different cb functions to have the same type. If this is the case you might need trait objects or at least function pointers anyways.

[Yandros]

@steffahn

impl<F: Fn()> Foo<F> {
    pub fn new() -> Foo<impl Fn()> {
        Foo { cb: || {} }
    }
}

This will cause type-inference issues, though. But it is indeed the starting point of the only non-dyn-based solution in stable Rust until we get min_type_alias_impl_trait.

I've discussed about this very pattern (impl Fn and returning such from an impl … { fn new() constructor) in this other post:

How to use Traits as Generic type parameters?

Although in this example it is just a matter of "style preference", the problem does indeed arrive when unnameable types are involved: let's image someone wants to have: struct Session<F : Fn()> { f: F, } impl Session<?> { fn new () -> Session<impl Fn()> { Session { f: || println!("Demo"), } } } your code example is similar to this situation, except that you could name the type but you don't want to, to ease refactoring. I already covered this use case in an old p…

I have also written a more general-purpose post (impl ArbitraryTrait from a function yielding an opaque type, such as -> impl Iterator…), listing all the current solutions to the problem (nightly feature, constructor with pseudo impl_Trait hidden type, dyn-erasure):

Embedding Trait inside of Struct

A simplified version of your problem is here: trait Foo { fn stuff (&self) ; } fn makes_foo () -> impl Foo { struct Struct; impl Foo for Struct { fn stuff (self: &'_ Self) { eprintln!("<impl Foo>::stuff()"); } } Struct } struct FooContainer<T : Foo> { field: T, } impl<T : Foo> FooContainer<T> { fn new () -> Self { Self { field: makes_foo(), } } fn other_stuff (self: &'_ Self) …

[steffahn]

@Yandros

This will cause type-inference issues, though.

Good point. I guess one could “cheat” even more badly and just use a concrete type different from what’s actually being returned

struct Foo<F: Fn()> {
    pub cb: F,
}

impl Foo<fn()> {
    pub fn new() -> Foo<impl Fn()> {
        Foo { cb: || {} }
    }
}

fn main() {
    let x = Foo::new();
}

I admit that this is pretty bad (as in: potentially wildly confusing), though. Maybe a standalone function would be nicer.

struct Foo<F: Fn()> {
    pub cb: F,
}

pub fn default_foo() -> Foo<impl Fn()> {
    Foo { cb: || {} }
}

fn main() {
    let x = default_foo();
}

[dakom]

wow, a lot of helpful info here, thanks y'all!

[dakom]

@OptimisticPeach

You generally can't name most types that implement the Fn* traits

By "naming" here, do you mean being able to literally type out the name in an assignment?

e.g.

fn foo() -> impl Fn() {
    || {}
}

fn main() {
    //fine
    let a = foo();
    
    //not fine
    let b: ??? = foo();
}

[quinedot]

@dakom

By "naming" here, do you mean being able to literally type out the name in an assignment?

Yes, sometimes also referred to as an opaque type or Voldemort type.