I'm not sure I know of anything in particular, unfortunately. It's a pretty small hack based around just the formal ideas of how these parameters work, and I don't know if there's any real place for that kind of knowledge to be stored right now?
I believe I personally learned about this sort of thing mostly through forum posts, various RFC threads & by internalizing an understanding of the trait system's exact behavior. The discussion and usage of unnameables is very closely related to impl Trait, so I might recommend reading the impl Trait RFC + the pull request thread for its introducution, but even then I'd be hesitant because there's a lot of extra information there not necessary to understanding the feature.
If anything, I think experimenting, doing weird things with the type system, observing the results, and seeing others' ideas might be the current best way to learn this.
I've been trying to play around with a lot of this kind of stuff. So perhaps, instead of banging my head against the wall for quite as long as I have been with this, I'll post here a bit more
RFCs have been something that I have been wanting to read through a bit more actually, so perhaps I'll get on with reading those. Starting with the one that you've linked.
I'll get on with implementing everyone's suggestions and seeing how it goes!
I'm close to having this solved, but I'm having issues storing (using either of your solutions) the FutureWrapper in another struct or returning one from a function. Would you have any advice on doing this?
Storing it again comes back to the same problem as storing the first future: in both of the options I present, rather that giving FutureFactory a nameable type, we kind of punt the "unnameable type" problem on to whoever is using FutureFactory.
Anything that stores either an async fn or any future combinations with closures without boxing it will be unnameable, and thus the chain of solutions either like these needs to continue until the future is either used directly from a local variable, or put into a Box like @najamelan suggested.
By "chain of solutions" here, I mean each level is either an async fn storing the future in a local variable, or a struct generic of what future it stores (like FutureFactory is).
There's value in not boxing things at every level, since each dyn Future introduces a level of dynamic dispatch, and every Box a new allocation, but at the same time it's standard to box the futures either at the top level in the executor, or whenever you want to store multiple different futures in the same list, or if you have a few levels of concrete structs and the clarity cost of generics isn't worth the small performanre gain of leaving things unboxed.
The futures crate has that nice FutureExt trait with the .boxed() method to construct a Pin<Box<dyn Future + Sync + Send>>, and a nice alias BoxedFuture for that long type. So it isn't the end of the world to box things, if you need to.
I can't make a specific suggestion without knowing exactly why you need to store them, but I hope this help! Let me know if thin makes sense, or what you end up going with!
