Ergonomics of `alt()` taking tuple versus slice

[t-mart]

Is there a reason alt() cannot take a slice of child parsers?

Instead, it takes a List, which is any of the 1- to 21-tuple implementations.

This is fine when the format for which you are trying to parse is known at compile-time/statically, but unusable when the format is only known at runtime.

For example, I'm writing a software-version bumper right now, and the user provides both their arbitrary format (e.g. yyyy.patch) and their current version (e.g. 2024.5) as inputs to my package/program. First, I have a parser for the format string (which is static-defined), but then I need to create a new parser from its result for the actual version string, which is runtime-defined. Therefore, this second parser cannot be made from a tuple.

I have been able to work around this by continually building a parser up in a "reduce" fashion, something like

parsers.reduce(|acc, p| acc.or(p))

(I believe that applying pairwise or() calls has the same effect as alt(), right?) Nonetheless, it's cumbersome, especially with the type annotations, for a newer Rust user like me: plenty of Box, dyn, lifetimes, Sized, etc.

So, I wonder why there isn't a version of alt that could take in a dynamically sized slice of child parsers.

Prerequisites

• Rust version: rustc 1.77.0-nightly (e51e98dde 2023-12-31)
• nom version : 7.1.3
• nom compilation features used: default ones

[epage]

alt for arrays was added in #1556 but that was after the start of 8.0. I've not seen any indication of how much remaining work Geal intends for the 8.0 release.

[epage]

Hmm, that is still just for a fixed size array and it sounds like you don't know the size of your array until runtime, right?

[Geal]

impemented in https://github.com/rust-bakery/nom/pull/1754, this will ship in nom 8, thank you for the suggestion