should function combinators return a FnMut?

[Geal]

some combinators return a impl FnMut(I) -> IResult<I,O,E> because a test was failing in tests/reborrow_fold.rs, but I'm not sure allowing mutability there is such a good idea. If people want to mutate data from inside a parser, using a Cell might be a better solution.

[loewenheim]

If I’m not mistaken, Fn can’t work in all cases. For instance, consider fold_many0. If it returned an Fn, we could run it as many times as we wanted and thereby multiply the init argument, which can’t be right.

But maybe I’m making a mistake somewhere, I’m no expert on Rust’s type system.

[Geal]

for fold_many0, we would need to make init Clone. In general, we have to assume any parser can be called multiple times, so they should at least return Fn or FnMut.
I added FnMut in delimited: https://github.com/Geal/nom/blob/master/src/sequence/mod.rs#L93-L94
to make this test compile: https://github.com/Geal/nom/blob/master/tests/reborrow_fold.rs#L12-L16
But now I'm not sure this is something that should be supported

[Geal]

all nom parsers are now Fn instead of FnOnce and FnMut. We should be able to call them multiple times, and they're not meant to modify their environment

[z2oh]

I was upgrading a parser from 4.0 to 5.0 and ran into an issue with fold_many0. I used this function to accumulate parts of an arithmetic expression into an AST. I made a decision a while ago to make my AST nodes non-clonable (since I figured this should never need to happen and I didn't want to be able to circumvent the borrow checker). I was able to fix my issue by having a custom implementation of the fold_many0 function that returned impl FnOnce instead of impl Fn.

Is it worth polluting the multi namespace with fold_many*_once variants of the fold_many functions to avoid the Clone bound where it is not needed? I would be happy to make a PR for this if desired, otherwise I can stick to my custom implementations of the functions.