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

expose scanner as public api #1186

Open
devsnek opened this issue Aug 25, 2024 · 1 comment
Open

expose scanner as public api #1186

devsnek opened this issue Aug 25, 2024 · 1 comment

Comments

@devsnek
Copy link

devsnek commented Aug 25, 2024

I realize this is a somewhat selfish request but I have a library for parsing JSON in Elixir (https://github.com/devsnek/jsont) which uses much of the logic from the SliceRead implementation in this library. I realized while reading through the more recent performance improvements here that this represents a pretty nice separation between the layer that implements serde and the layer that understands how to scan through JSON. If the scanner was a public API, it could be reused by other libraries like mine more easily. I think more concretely my ask is whether it would be ok to move the number logic into the read trait (which i think would also allow the String buffer used in the current number parsing logic to be removed for the slice case?) and then selectively remove the doc(hidden) from some of the methods.

@dtolnay
Copy link
Member

dtolnay commented Aug 25, 2024

I am on board with a PR to relocate the number parsing logic, if justified by a benchmark. However, I am opposed to turning our Read trait's details into a public API.

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

No branches or pull requests

2 participants