ParserInput is an implementation detail and should not be in the public API

[federicomenaquintero]

One creates a parser like this:

let mut input = ParserInput::new("foo: bar;");
let mut parser = Parser::new(&mut input);

... use parser ...
... input is never used again; has no methods but new() ...

I think we could go back to creating a parser with Parser::new(s: &'i str) based on the string's lifetime. If the parser wants to keep a cached token internally, which is the sole purpose of ParserInput, it can do that on its own.

[SimonSapin]

We used to do this and it was more ergonomic, but it required a memory allocation whose cost was non-trivial for parsing short strings like in JS/CSSOM element.style.left = "10px".

[SimonSapin]

Without allocation, if Parser owned ParserInput inline its sizeof would become much larger and this extra space would be wasted in the case of nested Parsers used in e.g. parse_nested_block.

Closing as I don’t think we’ll change this back unless a new idea comes up. Feel free to comment if there’s more to consider.

[federicomenaquintero]

Oh, I see, the nested parser also uses the same input. I hadn't seen that function before :)