Long term plan: Investigate strategies for non-owned types about proptest

[adaszko]

It’d be lovely to revisit this issue now that GATs have been stabilized. Has anybody experimented with it? :)

EDIT: A bit about my use case: Due to proptest not supporting non-owned types, I’m unable to randomly generate a tree value whose nodes are allocated in an arena (bumpalo) because I can’t store &Child references in the node type. I’m forced to allocate with Box::new() and Vec<> to create the nodes.

[AltSysrq]

I do think it'd be useful, but I also agree that this definitely requires GATs. (If trait aliases become a thing, there might also be a viable option of just adding a lifetime parameter to all the traits that most people wouldn't have to deal with.)

I think the problem bears a lot of similarity to "streaming iterators", so it might be best to wait and see how that gets solved and then follow suit.

[Centril]

Agreed, it is similar to streaming iterators. Once GATs lands I will do some prototyping on nightly to see how much the interface has to change to accommodate generation of borrowed types and how much we have to modify the strategies already provided.

If we find a good solution we can perhaps develop it as a separate branch and then merge it in once GATs for lifetimes are stabilized (which might be before GATs for types).

[Ten0]

Hmm while GATs may be the correct way to represent this, they look unlikely to be stabilized anytime soon, and I'm curious as to why this wouldn't work if Strategy and ValueTree were simply generic on 'a.
It feels to me it would work, with ValueTree holding the owned data and generating the non-owned structures on call to current. current on ValueTree would take &'a self.
We would always implement ValueTree and Strategy for every 'a and use for<'a> T: Strategy<'a> wherever required.