[throwaway894345]

I like Go a lot, but I often wish we could be more explicit about where allocations are. It’s often important for writing performant code, but instead of having semantics we have to check against the stack analyzer which has poor ergonomics and may break at any time.

But yeah, to your point, returning a slice in a GC language is not some exotic thing.

[onionisafruit]

I think I would like a “stackvar” declaration that works the same as “var” except my code won’t compile if escape analysis shows it would wind up on the heap. I say that knowing I’m not a language designer and have never written a compiler. This may be an obviously bad idea to somebody experienced in either of those.

I commented elsewhere on this post that I rarely have to think about stacks and heaps when writing Go, so maybe this isn’t my issue to care about either.

[Scaevolus]

This could probably be implemented as an expensive comment-driven lint during compilation.

[onionisafruit]

I don’t think it can be a true linter because it depends on the compiler. But it’s not a bad idea anyway

[Yokohiii]

Escape analysis sends large allocation to the stack. The information is there.

[Yokohiii]

Can you elaborate on the stack analyzer? All I could figure out was to see runtime.morestack calls that affected the runtime, but as far I remember the caller timings did exclude the cost. Having a clearer view of stack grow rates would be really great.

[throwaway894345]

I’m not sure what you mean? Are you asking for information about what it is or how to use it?

[Yokohiii]

I never heard of "stack analyzer" and didn't get meaningful results for it, do you mean escape analysis?

[throwaway894345]

Sorry, yes, I meant “escape analyzer”. I’ve been jet lagged.

[Yokohiii]

Ok no problem. Take a good sleep soon!