@Dreikin said in Go 1.8 is out:
So does anyone know the state of the art on computed disposal?
I'm not 100% up to speed, but compilers can do a hell of a lot where they know enough. “Know enough” requires determining where a memory object comes into being, where it ceases to be talked about through known references, whether the functions you call modify anything, and knowing that nobody's playing shenanigans with address arithmetic. Once you've got all that (actually pretty common where you've got the right annotations on your library functions) then it can work out where you've got genuine short-lived memory, and that's a candidate for migration to the stack (and other generalised trickery).
Compilers can also insert a lot of information about where variables are and when they're holding meaningful data. OTOH, when things absolutely must live on the heap and absolutely need to be passed around all over, everything gets more complicated. I've yet to figure out how to tell a compiler to assume that it is working with strictly a single thread and that memory objects don't cross thread boundaries (except in special areas) as that would allow the heap to be tamed more thoroughly, but that might be my lack of study…