-
Notifications
You must be signed in to change notification settings - Fork 5
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
Parser returns(including error type) need to be owned values. #9
Comments
Fixes #3 |
I was testing out this project on an exiting nom parser and was was also confused by this for some time. I'm probably betraying my lack of understanding here, but why exactly is it the case that only the top level parser needs to yield a Clone type? |
It's because the other parsers return a reference tied to the lifetime of the slice they are passed. When the top parser attempts to use that lifetime, the I think nom-bufreader needs to return the Edit: I now realize this leads to a self-referential type... The tuple being returned. Suffice to say, this is not easily solved except by changing core nom to have an owned return type for this case. |
Right, I see. Thanks. That indeed seems sticky. Perhaps it requires a special |
I'm glad there is interest in nom as I don't have the knowledge to take on a project like this. For example, I don't know how bad(if at all) it would be to force all the return types to be owned values. I will be embedding a modified version of this crate in my own crates. With that, I'm interested to know if there is a community that could offer support with setting design criteria. Having a super trait over |
This was impossible to figure out. The top-level parser should be forced to have
Clone
on its types, especiallynom
's default error type.The text was updated successfully, but these errors were encountered: