I can't imagine it was impossible to keep the inline-value optimization; after all, the full type information is always right there in the other word of the int

I can't imagine it was impossible to keep the inline-value optimization; after all, the full type information is always right there in the other word of the interface value, but I think it would have been too complicated/expensive for too little benefit. The bigger issue IMO is and has been that fat pointers (strings, slices) can't be inlined in interface values. There's definitely some benefit to inlining integers and floats, but the indirection that comes from not inlining them isn't that significant compared to the double-indirection that comes from not inlining strings and slices. There was some discussion on the mailing list IIRC about expanding the interface to 3 words wide (to hold strings at least) or 4 words wide (to hold slices too), but this was rejected as going too far the other way (at the time). Interestingly, the log/slog package does inline string values at least [1], and demonstrates how such a thing can be done when needed, albeit with a fair deal of complexity. [1]: https://cs.opensource.google/go/go/+/refs/tags/go1.23.1:src/log/slog/value.go;l=21 https://cs.opensource.google/go/go/+/refs/tags/go1.23.1:src/...