On Sunday, 4 November 2012 at 21:27:36 UTC, Walter Bright wrote:
You can't determine this, even at runtime, because you don't know what subsequent calls will use enough stack to overflow it.
Right, I didn't take into account that heap allocations use some stack anyway to store the pointers.
Since it's not possible to completely stop the stack from filling any further once it's been filled up, some kind of conservative heuristic should be used then for determining whether things should go on heap or not. That heuristic would be based on both compile-time and run-time analysis of the program. The heuristic cannot guarantee that there won't be a stack overflow, but neither can the programmer.
It's great that optimizations could be used to eliminate unnecessary heap allocations. But it could be interesting to imagine a language where it was impossible for the programmer to explicitly specify the allocation method. Things would go to heap if it was determined necessary by compile-time analysis, and also when the heuristics determine there might a danger of stack overflow. Otherwise things would go to stack. Pointers (or rather re-directable references) would always be used for referring to existing variables (that could be on heap or not). Pointers would never represent "a variable allocated on heap".
