Suggestion: Implement Default for function items

[DefinitelyNotRobot]

@bjorn3

Have you seen Add design notes for function-type Default implementation discussion by Diggsey · Pull Request #71 · rust-lang/lang-team · GitHub ? (there is some additional discussion at https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/design.20note.20lang-team.2371 )

Thanks for the link. Somehow I didn't encounter this issue on search engines.

@scottmcm

Why isn't this acceptable? Is the problem just that it's hard to store?

Imagine if I want to store a collection of different decorated functions which have the same signature. It's not possible to use impl Fn(SomeType) in that way directly except for statically dispatching it.

@elidupree

FWIW, I ran into a similar situation in a project of my own recently. My workaround was to make a trait with a method that doesn't take self , and implement that trait rather than writing free-standing functions. Given any implementor, you can make a second implementor that decorates it – and you can convert the method to a function pointer by specifying the generic parameter.

That sounds interesting. I thought to somehow use traits too but I didn't want to burden the consumer of my library to implement a trait for every freestanding function they give.

It seems that they'll have to create a dummy type so that they could do impl Trait for Dummy. I wonder if there is a way around that boilerplate?

@CAD97

In the mean time, you might try picking out a crate that'll give you StackBox<dyn Fn()> . It'll necessarily be a bit bigger than fn() would be, but it'll accomplish what you want.

Box<dyn Fn()> alone will fit my needs, considering the fact that function item types are ZST so I don't think any actual allocation will happen. I'm mostly trying to avoid the additional size and indirection of dyn Fn(), which may be costly as this is likely going to be one of the hottest loop in my code.