Specify `Fn` trait bound on struct definition without fixing one of the `Fn` parameters

Question

I have a struct that contains a function object:

struct Foo<F> {
    func: F,
}

I want to add an Fn trait bound to the struct definition. The problem is: I do care about the first parameter (it has to be i32), but not the second one. What I actually want to write is something like this:

struct Foo<F> 
where
    ∃ P so that F: Fn(i32, P),
{
    func: F,
}

So in English: the type F has to be a function that takes two parameters, the first of which is an i32 (and the second one can be anything). The syntax above is obviously not valid. I thought about three potential solutions:

1. The for<> syntax won't help here. Apart from the fact that it doesn't work for non-lifetime parameter yet, it is universal ("for all") and not existential ("there exists"). So that's out.

2. The other possibility is to add a type parameter to the struct. I already don't like that solution, because the parameter doesn't inherently belong to the struct.

   struct Foo<F, P> 
   where
       F: Fn(i32, P),
   {
       func: F,
   }
   

   But this doesn't work: the parameter P is not used, except in the where bound, so the compiler complains.

   This problem can be solved by adding a PhantomData<P> field, but this shouldn't be necessary and more importantly, users cannot use the struct constructor syntax easily anymore.

3. Lastly I tried this:

   struct Foo<F> 
   where
       F: Fn(i32, _),
   {
       func: F,
   }
   

   But this also doesn't work:

   error[E0121]: the type placeholder `_` is not allowed within types on item signatures
    --> src/main.rs:3:20
     |
   3 |         F: Fn(i32, _),
     |                    ^ not allowed in type signatures
   

Is there a way to achieve what I want?

---

Side note: Why do I want to have the trait bound on the struct already instead of just the impl blocks where it's important?

First, once the "implied trait bounds" RFC is implemented, this allows me to omit the duplicate trait bounds from all the impl blocks. Second, with this bound, it helps the compiler with its type inference. Consider this:

struct Foo<F, T> 
where
    F: Fn(T, _),
{
    data: T,
    F: F,
}

If the bound were possible (I tried it with the PhantomData "solution" above), the compiler can more easily infer the type of the closure's first argument. If the trait bounds would only be specified on impl blocks, the compiler has difficulties.

Answer 1

Rather than put constraints on the struct, the simplest and best approach is to put the constraints on the implementation of all methods that will need to use the function:

struct Foo<F, T> {
    data: T,
    f: F,
}

impl<F, T> Foo<F, T> {
    fn call_f<P>(&self, arg: P)
    where
        T: Copy,
        F: Fn(T, P)
    {
        (self.f)(self.data, arg);
    }
}

First, once the "implied trait bounds" RFC is implemented, this allows me to omit the duplicate trait bounds from all the impl blocks.

So it sounds like your main concern is about removing duplicate bounds. If that's the problem, you can try to group all the methods with the same bounds into a common impl, so you're still only ever write them once:

impl<F, T, P> Foo<F, T> 
where
    T: Copy,
    F: Fn(T, P),
{
    fn call_f(&self, arg: P) {
        (self.f)(self.data, arg);
    }
}

There's a little problem here, similar to the one you found yourself: unconstrained type parameter: P. However, now that we've got to here, you can solve it very simply by introducing a trait (you can name it better for your specific use case):

trait FIsAFunction<F, T, P> {
    fn call_f(&self, arg: P);
}

impl<F, T, P> FIsAFunction<F, T, P> for Foo<F, T> 
where
    T: Copy,
    F: Fn(T, P),
{
    fn call_f(&self, arg: P){
        (self.f)(self.data, arg);
    }
}

And users don't have to do anything weird^[1]:

fn main() {
    fn callback(x: u32, y: &str) {
        println!("I was given {:?} and {:?}", x, y)
    }
    let foo = Foo { data: 1u32, f: callback };
    foo.call_f("hello!");
}

---

_{[1] They may have to use the trait. Which isn't so weird: you already have to do that with a lot of std stuff, like std::io::Read etc.}

Answer 2

Solution #2 is the only way I know of to make this work with bounds on the struct. In my opinion making it work without bounds on the struct, as Peter Hall suggests, is usually preferable because it puts the bounds only where they are truly meaningful, but if you find that onerous, an extra type parameter is your only option.

2. The other possibility is to add a type parameter to the struct. I already don't like that solution, because the parameter doesn't inherently belong to the struct.

The second parameter is necessary. The types of the arguments of a Fn-implementing type are parameters of the Fn trait, so in principle you could have both impl Fn(i32, i32) for X and impl Fn(i32, String) for X, just as you can have both impl AsRef<i32> for X and impl AsRef<String> for X.

In fact, if you don't look at it too hard, this is kind of how HRTBs already work: a function can implement Fn(&'x i32) for some particular lifetime 'x, or it can implement for<'a> Fn(&'a i32), which means there are an infinite number of possible Fn traits that it implements.

But you found the problem of adding a parameter for P: the parameter is unused.

This problem can be solved by adding a PhantomData<P> field, but this shouldn't be necessary

The compiler peers inside structs to determine the variance of their parameters. In this case, suppose P is a reference type. Is it safe to pass a Foo<_, &'static T> to a function expecting a Foo<_, &'a T>? What about the other way around?

(As the linked answer states, constraints -- where clauses -- don't count for determining variance, which is why PhantomData is necessary here.)

But the PhantomData member shouldn't be PhantomData<P>, because Foo<_, P> doesn't contain a P. It contains a function that takes a P as an argument. Instead, you should use PhantomData<fn(P)>, which signals to the compiler that the variance of Foo<F, P> in P is the same as the variance of fn(P) -- a function (pointer) taking P. In other words, Foo is contravariant in P. To the human reader, this might seem redundant -- after all, we already have an F member, and F must be contravariant in P. But, well, the compiler isn't really smart enough to draw that conclusion, so you have to spell it out.

(See the section of the Nomicon on subtyping for a more rigorous explanation of variance.)

Which brings me to your final objection:

and more importantly, users cannot use the struct constructor syntax easily anymore.

Unfortunately, I can't think of a solution to this besides "write a nice constructor function". Perhaps a smarter compiler will one day lift this burden, but for now, PhantomData is what we have.