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.
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.
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 implementsserde
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 theString
buffer used in the current number parsing logic to be removed for the slice case?) and then selectively remove thedoc(hidden)
from some of the methods.