While you are of course 100% correct, in the context of discussing escape analysis I find it odd to say that it's essentially not "real".

Like any optimization, it makes sense to talk about what "will" happen, even if a language (or a specific compiler) makes no specific promises.

Escape analysis enables an optimization.

I think I understand you to be saying that "escape analysis" is not why returning a pointer to a local works in Go, but it's what allows some variables to be on the stack, despite the ability to return pointers to other "local" variables.

Or similar to how the compiler can allow "a * 6" to never use a mul instruction, but just two shifts and an add.

Which is probably a better way to think about it.

> So clearly you don’t need to think about the details of escape analysis to understand what your code does

Right. To circle back to the context: Yeah, OP thought this was due to escape analysis, and that's why it worked. No, it's just a detail about why other code does something else. (but not really, because OP returned the slice by value)

So I suppose it's more correct to say that we were never discussing escape analysis at all. An escape analysis post would be talking about allocation counts and memory fragmentation, not "why does this work?".

Claude (per OPs post) led them astray.