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
UnitFn or whatever it would be called. (In most cases, however, being able to have a
fn… 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
No it's not, you cannot implement through a type-alias-impl-trait.
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?
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.