It means more boxing, are you should it doesn't regress performance/memory?

Yes I am aware this will slightly regress perf (probably), but I believe this to be neglible in the grandscheme. These are the rarer cases anyways. I prefer the readability of less macros and also favor the solution here that is less complicated and uses less unsafe. Feel free to argue against it though, should've probably not self-merged this one, sorry :^)

I honestly don't know. Paths are extremely common, and even though most of them are BarePath, a non-negligible part has generics (I don't remember the ratios, but I once checked that). Boxing them may turn too much. I guess we will need a benchmark to be sure, I'll try to check it later.

So I benchmarked this and this does not regress memory/time (lowering probably takes a fraction of time/memory, the most significant is inference), so this generally gets an approval from me. However I do think we need to bring EmptyOptimizedThinVec back, as it's used in diagnostics (and will be used more with the diagnostic queries I'm writing), so might as well use it for tuple types.

My bad, I now see that ThinVec::new() will not allocate, so we can keep it as is.

Cool, thanks for double checking this