When is a choice really consumed/determined?

[DasLixou]

When I have a choice with two parsers, and the first one does an intermediate .map_with, so it's stateful, and then we .then(just("!")) which isn't what we read the that the first path "errors".
Does this lead to the second choice not being evaluated (and if so, when is the point where this doesn't happen anymore?), or will the state now be in a weird state or is map_with lazy and only evaluated when it completely succeeded? And when yes, is order preserved?

[zesterer]

Chumsky will try matching the input with each option in a choice until it finds one that parses the input. If none of them can successfully parse the input, the parser backtracks.

If there are no other parsers 'higher up' in the parse tree that can parse the input, then an error will be produced.

map_with lazy and only evaluated when it completely succeeded?

It's not lazy, no (or, at least, it's allowed not to be). As mentioned here, closures should be 'conceptually pure' as chumsky can decide to optimise them away if it doesn't need to use them.

If your parser state needs to support rollback on failure, you might want to use one of the non-standard state types like RollbackState or TruncateState.

[DasLixou]

Yeah, I already have smth like TruncateState (but with a bit more) written myself.
The problem is that I don't want to preserve something as parser output because I use .repeated() often, which would then unneccessarily allocate Vectors and basically make the whole idea of the arena pointless.

[Zij-IT]

Vec doesn't allocate for zero sized structs ;) You could use .collect<Vec<()>>() though I believe chumsky also has .collect<usize>() which gives you the count of the elements parsed.

[DasLixou]

ohh that sounds interesting O.o - I still wonder, is there any motivation for making this a little bit less hacky and better supported?

[DasLixou]

Okay so I've changed .then(attributes.repeated()) into .then(attributes.repeated().collect::<()>()) and that made it work.
I would however really appreciate better support for those situations, as I now have to merge multiple () expressions into one where I otherwise would just call ignore. Maybe have a on_success or so thing that explicitly is seperate from the output and always runs or so.

[DasLixou]

So far painpoints are .map(|_| ()).repeated().collect::<()>() instead of ignore() and a.then(b).then(c).map(|_| ()) instead of b.delimited_by(a, c)