Open zesterer opened 12 months ago
Sad to see lexical
being unsound and stale. parse_partial(&[u8])
really makes a performance difference. Can https://github.com/aldanor/fast-float-rust be considered as an alternative?
I think the parse_partial
function from fast-float
would work nicely with chumsky, yes (the API is pretty much identical to the one exposed by regex-automata
, which we use for the regex
parser). As for integer parsing: I'm less certain, although there are less complexities around integer parsing so implementing our own fast integer parser might not be too difficult.
Do I understand correctly that the list of examples not yet ported to 1.0 are those in the examples/ sub-directory that do not have an [[example]]
section? Update: My understanding is corrected; for example, foo
is updated but does not have an [[example]]
section.
Sad to see
lexical
being unsound and stale.parse_partial(&[u8])
really makes a performance difference. Can https://github.com/aldanor/fast-float-rust be considered as an alternative?
lexical appears to be fixed and the maintainer is back (:
That's good to know!
A list of things that need doing before 1.0 can be released as stable. This list will grow as we become aware of more things or remember outstanding issues.
API
General
ParserSealed
is necessary (perhapsdoc(hidden)
is sufficient for semver? Should we take a 'it's your fault if you don't read the docs' perspective?)sync
feature is broken. When enabled, it adds extraSend
/Sync
constraints to trait object parsers likerecursive
, thereby making it non-additive.IterParser
API overhaul from #425lexical
crate (apparently it has soundness issues and is unmaintained?)SimpleSpan::new
in favour ofSpan::new
, which is more general.Combinators
map_*
,try_map_*
,foldl_*
andfoldr_*
combinators into one (see #537).Vec<Operator>
or something of the sort, see here)recursive
(#494 seems like a good candidate)text::ident
a distinct type (instead of returning animpl Parser
), allowing us to propagate trait bounds through properlyInputs
CopyStream
(that copies the iterator instead of caching tokens, more performant for iterators with very little state, likelogos
iterators)Stream
: isIterInput
more sensible?Input::spanned
take a 'full input' span rather than an 'end of input' span? Might be more general.Errors
RichReason::Many
Extension API
Documentation
Examples
Guide
Other work