Right now, if I try to call a trait method defined on a function pointer using a function item as a receiver, the compiler complains that the function item type doesn't implement the trait. This doesn't seem like useful behavior, since the programmer can't implement traits on function items. I think that if the function item doesn't implement the trait, it should be coerced to a function pointer.
AFAICT implementations on function pointers is the only way to define a trait on several function types, since blanket implementations with Fn bounds conflict with each other.
I can see the value of being able to .clone() a function item and get a zero sized result, so the coercion shouldn't happen in all cases.
The dot operator already "performs a lot of magic" so this is in line with existing design choices.
Imho, this is rather the issue that should be tackled: the Fn… family of trait stops at Fn, without going to that extra step of FnItem / or FnConst or UnitFn or whatever it would be called. (In most cases, however, being able to have a constfn… generic parameter was deemed to be just as good, and there was some talk about trying to add support for it).
In the meantime, one of the closest ways to get close to an FnItem is to use impl 'static + Send + Sync + Copy + UnwindSafe + Unpin + Eq + Ord + Debug + FnOnce(…) -> …, but we will never get the option to coerce such a generic / existential type back to an fn pointer (there is not even impl Into<fn(…) -> _> for fn items): one has to keep forwarding that generic type around.
In fact, they can. By using the unstable impl Trait feature, it's definitely possible to give names to function item types, and then use that in impl blocks.
Given that type-alias-impl-trait is not yet released, i have never heard of this restriction (yet), so this is news to me. I wonder if this restriction is temporary or intentional?