Great cleanup, thanks!

The error gets always created if the compiler isn't smart enough
to move it into the right places. It is boxed, so this means one heap allocation/deallocation
on every call to deserialize_char?

Ah yeah. I think this code was written prior to error-boxing, and I must have missed it in code review. This allocation should probably be avoided as I'm pretty sure the compiler isn't smart enough to remove. If you want to take this on in your PR, I'd put error creation into a closure, and call it when an error occurs. If not, I'll address it in a follow-up PR.

The big UTF8_CHAR_WIDTH table and the utf8_char_width function could be replaced with something like (leading_zeros)

I'm pretty sure that I benchmarked this earlier and found that the lookup table was faster. That might have been specific to the architecture that I was on though? It looks like most CPUs have a pretty fast LZCNT instruction.

I'd put error creation into a closure, and call it when an error occurs. If not, I'll address it in a follow-up PR.

let error = || { 
    ErrorKind::InvalidEncoding{
        desc: "Invalid char encoding",
        detail: None
    }.into()
};
...
if width == 0 { return Err(error())}

Like this?

I'm pretty sure that I benchmarked this earlier and found that the lookup table was faster. That might have been specific to the architecture that I was on though? It looks like most CPUs have a pretty fast LZCNT instruction.

I must admit I had no performance benefits in mind. I guess the bit twiddling + match might be slower than the lookup table.

Like this?

Yep!

I must admit I had no performance benefits in mind. I guess the bit twiddling + match might be slower than the lookup table.

Yeah. I'll file an issue to do more benchmarking at a later date.

👍