Why is the cache API still unstable?

[Techcable]

I could not find reasoning for this. Is it because there are bugs or soundness issues?

[zesterer]

Simply put: I'm not very confident that it's had enough people using it and exploring its pros and cons to be 100% sure of the API. I'd very much welcome your feedback on it!

[gbj]

One thing I ran into just now while trying to use it: presumably it works best when parsers are Send + Sync, so the cached parser can be stored in a static LazyLock. However, the internals of some of the parsers are written to be single-threaded. For example, my (fairly simple) lexer could be cached easily (and the API for doing so is straightforward and nice.) However my parser uses recursive(), and RecursiveInner constructs an Rc, so any parser using recursive() can't actually be stored in a static. It could be stored in a therad-local, of course, but that might not be ideal.

You may have had other conversations elsewhere about thread-safety of parsers -- if so, apologies! IMO it is mostly relevant when talking about caching, because without caching you'd just construct a parser and use it on the same thread.

[Zij-IT]

There is #823 which talks about using Arc<_> instead of Rc<_> for Recursive<_>, but without people like yourself commenting it's difficult to judge how useful to Chumsky users such a change is (:

[zesterer]

Yes, I encountered this exact issue and it's the motivating factor for #889, which effectively makes Send+Sync a requirement for recursive/boxed parsers. I would prefer if this were an opt-in thing, but unfortunately I can't think of a way to have this work given that going through a trait object for the recursive section is pretty much a requirement.

When I finally get the time to merge this, Cache should become a lot more useful.

[zesterer]

Context in #933