Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

final_parser can't guess type arguments #14

Open
quomat opened this issue Apr 1, 2023 · 2 comments
Open

final_parser can't guess type arguments #14

quomat opened this issue Apr 1, 2023 · 2 comments

Comments

@quomat
Copy link

quomat commented Apr 1, 2023

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
Copy link
Owner

Lucretiel commented Apr 4, 2023

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
Copy link

BGR360 commented Dec 2, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants