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

Parser returns(including error type) need to be owned values. #9

Open
cheako opened this issue Nov 27, 2021 · 5 comments
Open

Parser returns(including error type) need to be owned values. #9

cheako opened this issue Nov 27, 2021 · 5 comments

Comments

@cheako
Copy link

cheako commented Nov 27, 2021

This was impossible to figure out. The top-level parser should be forced to have Clone on its types, especially nom's default error type.

@cheako
Copy link
Author

cheako commented Nov 27, 2021

Fixes #3

@kyzyl
Copy link

kyzyl commented Dec 8, 2021

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?

@cheako
Copy link
Author

cheako commented Dec 8, 2021

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 &[u8] that is created and owned by nom-bufreader, it breaks because the caller into nom-bufreader does not own the slice being matched against.

I think nom-bufreader needs to return the Vec<u8> it's matching against, this is perhaps the best/most nom like solution.

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.

@kyzyl
Copy link

kyzyl commented Dec 9, 2021

Right, I see. Thanks. That indeed seems sticky. Perhaps it requires a special BufferedParser type which is what this crate's parse requires, that just yields the bare type, not a tuple with the remainder buffer. As you say it doesn't seem possible to keep it compatible with existing nom types. It seems like Rust is highlighting here the fact that the concept of 'returning' the underlying buffer that is currently being streamed into is not well defined. Although maybe this is a problem that has been thought about elsewhere. I'm not that familiar with the particulars here.

@cheako
Copy link
Author

cheako commented Dec 9, 2021

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 nom::Parser sounds like the right call... Though I haven't needed to look closely at it.

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

2 participants