Damn, there's some astonishing writing skills going on here

It's foremost a naming problem, FixedBufferAllocator doesn't hint that it is actually is a bit of a weird mix of a bump and stack allocator (IMHO if it would be a bump allocator it shouldn't have a free function at all, and for a stack allocator the free function should probably be called pop).

However both doesn't match Zig's expected alloc/free allocator interface, which is an interesting design challenge on its own.

Not at all. Viewed one way it isn't a problem at all (the user found and fixed the issue). Viewed another way, it is a flaw in the docs for FixedBufferAllocator that it offers a "free()" call but fails to make clear that this only works when freeing at the end of the allocated region.

The fact that you ask why it needs to be inlined means you haven't understood how the feature works. If you did, you'd be a fan. It's a general mechansim that fits Zig perfectly, along with inline for and while.

I understood why. I said it is very non-obvious and opaque at first read, so it might trip up a lot of newcomers.

Surely there's better ways to express interfaces than exploiting a brilliant side-effect of compile time inlining.

Learn to C

I'm hearing it's a mistake (I'm signing up just to share this, as a former assistant of his). But what I'm hearing could be wrong as well... in short, I would await an official press release from Princeton.