ParseTo trait using using generics wrong

[marcdejonge]

Hi!

I was working on a project to generate nom parse functions using macros. But I'm running into the problem that automatically supporting floating numbers is hard, because of how the ParseTo trait is implemented. For example, the float function currently expects that ParseTo<f32> should be implemented. But to support this in my generic trait, every potential importer would need to add that constraint.

I think that the type R on ParseTo should not be on the trait itself, but on the function. Then the trait becomes easier to use. An improved version would look something like:

pub trait ParseTo {
  fn parse_to<R: FromStr>(&self) -> Option<R>;
}

I'll work on a PR to open soon, so we can check the impact.

[Geal]

that looks useful yes, but that's not someting I would merge for the moment, as that will make a breaking change in the public API. Noting this for nom 9

[marcdejonge]

Thanks. I've worked around this in my library for now, by implementing my own float parsing. Then I don't need to use this trait at all. I would also see if the trait could be removed completely, because it seems to only be used in these functions.