itoa VS ucd-generate

The hyper package for the crab language actually has a dependency on a package that does itoa (among others) so IMO the problem exist there too and most non trivial packages will be bloated

I see itoa which seems trivial on the surface. The implementation is highly optimized, but it's also covering all the different cases. I'm guessing this is for printing match counts or line numbers, and if this is actually a bottleneck for ripgrep — which seems unlikely — then maybe it's worth it. You know your own needs, and if it was a bottleneck, I bet you could do just as well, if not better, with a custom, smaller, simpler solution inside ripgrep. (i.e. just make sure the power-of-ten denominators are available at compile time so the compiler won't generate divisions.)

So you're saying that the 'expect()' message when a regex compilation error occurs should be a translation from a terse domain specific language to bloviating prose? :-)

What 'expect()' message would you write for this regex? https://github.com/BurntSushi/ucd-generate/blob/6d3aae3b8005...

I think 'unwrap()' there is perfectly appropriate.

> I think it'd be desirable to have a `.unwrap_with_context("Context: {}")`, and the you'd get `Context: Inner Panic Info`.

Why?

I've also embedded Unicode tables a number of times. It's very easy to do, and I do it enough that I even have a tool to do it. Having tooling and scripts to do it is important for reasons of provenance and also for when the tables need to be updated (every year or so).

ucd-generate for generating Unicode tables. It is what the regex crate uses to generate all of its tables, and it supports many properties already. It also provides a way to represent Unicode character names in a compressed data structure.