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 {
    func: F,
}

I want to add an Fn trait bound to the s

Answer 1

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 for X and impl AsRef 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

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

, because Foo<_, P> doesn't contain a P. It contains a function that takes a P as an argument. Instead, you should use PhantomData, which signals to the compiler that the variance of Foo 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.