is there a particular reason why this is not allowed?
fn my_function(){
.....
}
impl MyTrait for my_function{
}
i feel like if i can implement for a generic fn i should be also able for an exact one
i know i can easily cirumvent this by simply making a trait with both fn and use that but in my usecase it was just way cleaner to be able to do this where you would write the first function and have the second made through macros
fn some_fn(m:SomeEnum){
match m{
SomeEnum::A=>a()
SomeEnum::B=>b()
SomeEnum::C=>c()
}
impl WithMetaData for somefn{
fn get_metadata()->Meta{
let mut meta=Meta::new();
meta.insert(SomeEnum::A,<a as WithMetaData>::get_metadata());
meta.insert(SomeEnum::B,<b as WithMetaData>::get_metadata());
meta.insert(SomeEnum::C,<c as WithMetaData>::get_metadata());
}
}
Aside from there being no way to refer to your fn my_function() intrinsic type, as opposed to its plain my_function handle; going against the PLA doesn't seem like a great idea. For all intents and purposes, your fn function() is a distinct value. An instance of a virtual family of types comprising the whole of fn item(<args>) perhaps, yet a distinct value nonetheless.
Implementing traits - meant to abstract common traits of behaviour in between different types; each being an abstraction itself over the set of the distinct values it can hold - 2 for a bool, 256 for a u8, infinitely many for a &str- on concrete singular elements in these sets, would mean backpedaling against the very nature of the trait as a "type class". All for what?
Another party trick, akin to let (): ((())) = (((((((())))))));?