Standard traits not derived for function pointers with different calling conventions

[jethrogb]

use std::fmt::Debug;
use std::hash::Hash;

fn a<T: Hash + Ord + Eq + Clone + Debug>() {}

fn main() {
    a::<fn()>(); //OK
    a::<extern fn()>(); //OK
    a::<extern "C" fn()>(); //OK
    a::<extern "win64" fn()>(); //Error
    a::<extern "system" fn()>(); //Error
}

Errors:

error[E0277]: the trait bound `extern "win64" fn(): std::clone::Clone` is not satisfied
error[E0277]: the trait bound `extern "win64" fn(): std::cmp::Eq` is not satisfied
error[E0277]: the trait bound `extern "win64" fn(): std::cmp::Ord` is not satisfied
error[E0277]: the trait bound `extern "win64" fn(): std::fmt::Debug` is not satisfied
error[E0277]: the trait bound `extern "win64" fn(): std::hash::Hash` is not satisfied
error[E0277]: the trait bound `extern "system" fn(): std::clone::Clone` is not satisfied
error[E0277]: the trait bound `extern "system" fn(): std::cmp::Eq` is not satisfied
error[E0277]: the trait bound `extern "system" fn(): std::cmp::Ord` is not satisfied
error[E0277]: the trait bound `extern "system" fn(): std::fmt::Debug` is not satisfied
error[E0277]: the trait bound `extern "system" fn(): std::hash::Hash` is not satisfied

[petrochenkov]

See #38848 (comment) for the reasons.

[jethrogb]

I guess the cause for this is similar to reasons that various traits are not defined for very long tuples, arrays over 32 elements, etc. and apparently function pointers with long argument lists. If libcore bloat is an issue, should the compiler instead insert the necessary definitions automatically when needed? Or we need to come up with syntax for "all tuples", etc.

[jonas-schievink]

The tuple case can be handled via variadic generics. The fn pointer case, not so much (unless all of them implement a suitable common trait by magic).

[jethrogb]

fn-pointer case could also be handled by variadic generics, for the argument list at least. Then you just need one entry per calling convention which hopefully doesn't result in too much bloat. Array case could of course be handled by integer generics.

Are variadic generics something that is seriously considered for Rust's future? If so, we probably still need some kind of stop-gap measure here. If not, we'll need a more definitive solution here.

[jonas-schievink]

Are variadic generics something that is seriously considered for Rust's future?

Well, there's rust-lang/rfcs#1935

[asquared31415]

Update: the example code now compiles.

[Dylan-DPC]

Closing this as the example now compiles