Summary

Create a FunctionPointer trait that is "fundamental" (in the coherence sense) and built-in to the compiler. It is automatically implemented for all fn types, regardless of any other details (ABI, argument types, and so forth).

Motivation

You can't write an impl that applies to any function pointer

It is not possible to write an impl that is parameteric over all fn types today. This is for a number of a reasons:

  • You can't write an impl that is generic over ABI.
  • You can't write an impl that is generic over the number of parameters.
  • You can't write an impl that is generic over where binding occurs.

We are unlikely to ever make it possible to write an impl generic over all of those things.

And yet, there is a frequent need to write impls that work for any function pointer. For example, it would be nice if all function pointers were Ord, just as all raw pointers are Ord.

To work around this, it is common to find a suite of impls that attempts to emulate an impl over all function pointer types. Consider this code from the trace crate, for example:

trace_acyclic!(<X> fn() -> X);

trace_acyclic!(<A, X> fn(&A) -> X);
trace_acyclic!(<A, X> fn(A) -> X);

trace_acyclic!(<A, B, X> fn(&A, &B) -> X);
trace_acyclic!(<A, B, X> fn(A, &B) -> X);
trace_acyclic!(<A, B, X> fn(&A, B) -> X);
trace_acyclic!(<A, B, X> fn(A, B) -> X);
...

Or this code in the standard library:

Bug fixes in rustc endanger existing approaches

As part of the work to remove the leak-check in the compiler, we introduced a warning about potential overlap between impls like

impl<T> Trait for fn(T)
impl<U> Trait for fn(&U)

This is a complex topic. Likely we will ultimately accept those impls as non-overlapping, since wasm-bindgen relies on this pattern, as do numerous other crates – though there may be other limitations. But many of the use cases where those sorts of impls exist would be better handled with an opaque FunctionPointer trait anyhow, since what they're typically really trying to express is "any function pointer" (wasm-bindgen is actually somewhat different in this regard, as it has a special case for fns that taken references that is distinct from fns that taken ownership).

Proposal

Add in a trait FunctionPointer that is implemented for any fn type (but only fn types). It is built-in to the compiler, tagged as #[fundamental], and does not permit user-defined implementations. It offers a core operation, as_usize, for converting to a usize, which in turn can be used to implement the various built-in traits:

#[fundamental]
pub trait FunctionPointer: Copy + Ord + Eq {
    fn as_usize(self) -> usize; // but see alternatives below
}

impl<T: FunctionPointer> Ord for T {

}

impl<T: FunctionPointer> PartialEq for T {
    fn eq(&self, other: &T) -> bool {
        self.as_usize() == other.as_usize()
    }
}

impl<T: FunctionPointer> Eq for T { }

In terms of the implementation, this would be integrate into the rustc trait solver, which would know that only fn(_): FunctionPointer.

As with Sized, no user-defined impls would be permitted.

Concerns and alternative designs

  • Will we get negative coherence interactions because of the blanket impls?
    • I think that the #[fundamental] trait should handle that, but we have to experiment to see how smart the trait checker is.
  • Will function pointers always be representable by a usize?
    • On linux, dlsym returns a pointer, so in practice this is a pretty hard requirement.
    • Platforms that want more than a single pointer (e.g., AVR) generally implement that via trampolines or other techniques.
    • It's already possible to transmute from fn to usize (or to cast with as), so to some extent we've already baked in this dependency.
  • Seems rather ad-hoc, what about other categories of types, like integers?
    • Fair enough. However, function pointers have some unique challenges, as listed in the motivation.
    • We could pursue this path for other types if it proves out.
  • What about dyn Trait and friends?
    • It's true that those dyn types have similar challenges to fn types, since there is no way to be generic over all the different sorts of bound regions one might have (e.g., over for<'a> dyn Fn(&'a u32) and so forth).
    • Unlike fn types, their size is not fixed, so as_usize could not work, which might argue for the "extended set of operations" approach.
    • Specifically one might confuse &dyn Fn() for fn().
    • Perhaps adding a fundamental DynType trait would be a good addition.
  • What about FnDef types (the unique types for each function)
    • If we made FunctionPointer apply to FnDef types, that can be an ergonomic win and quite useful.
    • The as_usize could trigger us to reify a function pointer.
    • The trait name might then not be a good fit, as a FnDef is not, in fact, a function pointer, just something that could be used to create a function pointer.
  • What about const interactions?
    • I think we can provide const impls for the FunctionPointer trait, so that as_usize and friends can be used from const functions

Alternative designs

Instead of the as_usize method, we might have methods like ord(Self, Self) -> Ordering that can be uesd to implement the traits. That set can grow over time since no user-defined impls are permitted.

This is obviously less 'minimal' but might work better (as noted above) if we extend to exotic platforms or for dyn types.

However, it may be that there is extant code that relies on converting fn pointers to usize and such code could not be converted to use fn traits.

Select a repo