Input lifetimes about chumsky HOT 4 CLOSED

I can live with it though. Now the code looks like this:

fn string<'i>() -> impl Parser<'i, Expression> { ... }
fn boolean<'i>() -> impl Parser<'i, Expression> { ... }

which isn't too bad

from chumsky.

The example you’ve posted is definitely how the lifetimes are intended to be used. I can totally understand how switching from .9 to 1.0 was rough though.

There is work being done on a migration guide if I am not mistaken, that should hopefully limit these pains in the future (:

from chumsky.

Yeah, a guide would definitely help. I think I already figured out most of it (I was missing chain, for example), but it took me a day. A guide would reduce that time spend

from chumsky.

Unfortunately, this is mostly due to limitations in Rust's lifetime solver. Ideally, we'd have retained Parser not having a lifetime and instead do something like this:

trait Parser {
    type Input<'a>;
    type Output<'a>;

    fn parse<'src>(&self, input: Self::Input<'src>) -> ParseResult<Self::Output<'src>>;
}

// And therefore parser functions could look like
// (on second thoughts, this signature is far more horrible to read than 1.0 today)
fn expr_parser() -> impl for<'src> Parser<Input<'src> = &'src str, Output<'src> = Expr<'src>> { ... }

Unfortunately, due to horribleness around variance rules, Rust doesn't currently accept this (and is unlikely to any time in the near future), so we're stuck with binding parsers to the lifetime of the input that they parse. In 1.0.0-alpha.6 we introduced Cache, which allows safely writing parsers independently of a specific lifetime thanks to a GAT trick, although it's admittedly a little more awkward than I'd prefer.

Regarding chain: this functionality is mostly replaced by the ability to take slices of the input (see the to_slice combinator).

from chumsky.