Lucretiel / nom-supreme

A collection of utilities for a superior nom experience
Mozilla Public License 2.0
149 stars 11 forks source link

final_parser can't guess type arguments #14

Open quomat opened 1 year ago

quomat commented 1 year ago

Hi, first of all, thank you for making such a great library! I just wanted to talk about a minor inconvinence I've encounter, I wonder whether is there any way to resolve it.

In the following code, I have a generic nom parser. I wanted to use the function final_parser on it, but it doesn't compile.

use nom::{character::complete::alpha1, IResult, Parser};
use nom_supreme::final_parser::final_parser;

fn parser(input: &str) -> IResult<&str, String> {
    Ok(alpha1.map(String::from).parse(input)?)
}

fn main() {
    let s = "str";
    let parsed = final_parser(parser)(s).unwrap();
                          ^^^^^^^^^^^^ - cannot infer type for type parameter `E2` declared on the function `final_parser`
    println!("{}", parsed);
}

It would be ideal for final_parser to infer the errors, just like one can work with nom IResult type without saying error types explicitly.

Lucretiel commented 1 year ago

I agree this would be ideal, but I'm not sure it's possible under the current type system. One of the main purposes of final_parser is to do an error conversion via ExtractContext, which usually means the output error type is different than the parser error type. I can investigate whether it's possible to add a defaulted type parameter there.

In the meantime, a typical workaround is to add an explicit type annotation to the output type:

let parsed: Result<String, ()> = final_parser(parser)(s);
let parsed = parsed.unwrap();
BGR360 commented 11 months ago

In the meantime, a typical workaround is to add an explicit type annotation to the output type

It would be really helpful to provide that in an example on the function's doc comment.