Combining those lets you remove (almost) all uses of malloc (and non-C equivalents like Box<T>) from a heck of a lot of programs, which makes life so much easier.

But what if you want to return an allocated object to your caller? You can't use a locally scoped arena for that, for the same reason you can't return a pointer to a stack-allocated object. But you can solve this by having a second arena bound to a wider scope, eg. a single frame in a video game

Arenas can support a stack of scopes, with automatic unwinding of each scope once it's finished. You can bind those scopes to function calls (especially easy in C), or to whatever logical subdivisions of your program you want, giving you a nicer replacement for alloca and variable-length arrays.

For anyone who is out of the loop on that reference, I am a deeply uncool nerd

Found it

Wait, it's more than that: f-strings are documented as aligning numbers to the right and everything else to the left by default. Which is both internally inconsistent, *and* inconsistent than the old %s formatting which right-aligns everything by default.

*can't just manipulate the exponent if you have to deal with infinities / NaNs / subnormals, to be clear

I forgot that you can use ldexp with a mantissa that isn't in [1, 2) :P

I suspect the "why" is because of a combination of supporting large exponents (can't use `x * (1<<n)` if n=100) and edge cases (can't just manipulate the exponent). So it's slow in software, but shouldn't be too bad in silicon.

But why *shouldn't* I be able to write `1.5 << x`, and have it translate to a single instruction which just alters the exponent (+ handles any special cases)? Why do we instead have to write `1.5 * (1 << x)`, and have that translate to three instructions, including a generic floating-point multiply?