And Then or Flat Map function

[hawkw]

Here's a feature request for something I think would be useful.

The map function can be used to apply a function to the successful result of a parser. I propose the addition of an additional function which applies a function returning Result to the successful result of a parser. If that function returned an error, the error value would be carried over as the ParseResult's error value, otherwise, it carries over the new success value.

I'm not quite sure what the idiomatic Rust name for this would be. In Scala, which I'm more familiar with, this is referred to as flatMap, while Rust's Result type calls it and_then. Whatever it's called, I think this would be a pretty useful feature.

[hawkw]

I might just go ahead and fork the repo and implement it myself, if I have the time.

[Marwes]

There is the function then already. I would not be opposed to having both though if you think its useful. Maybe the current function should just be replaced with the one you proposed. Looking through my code the only time I use it I could just as well have then return a result instead of a parser.

[hawkw]

There is the function then already.

Yeah, I did see the then function, but I was not really sure if it could be used for this purpose since it returns a parser.

The use case I have in mind here is parsing some strings that represent numbers, and then turning them into numeric values using from_str(), which returns a Result. It would be great if instead of

many1(hex_digit())
    .map(|x| char::from_u32(u32::from_str_radix(x, 16).unwrap()).unwrap())

I could just say

many1(hex_digit())
    .and_then(|x| u32::from_str_radix(x,16))
    .and_then(|x| char::from_u32(x))

This way, I could avoid using unwrap(), and have the error result from either from_str_radix or from_u32 carried over as a parse error.

Just my two cents. I know I would definitely find this pattern useful.

[Marwes]

One problem with your proposed function is that it needs a FromError implementation for ParseError. Nothing that isn't solvable but I though I should point it out. As ParseError is currently it would probably mean converting the error to a string and using Message variant though I would be open for suggestions for a better handling of user created errors.

[hawkw]

Ah, true, I hadn't thought of that. Well, put this one on the back burner for if/when you have time, I suppose.

[Marwes]

Closed through #28.