<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 7, 2015, at 10:36 AM, Joe Groff via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Alegreya-Regular; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">If weren't already been chased away by 'vars are always allocated on the heap'. The docs generally discuss high-level semantic behavior rather than the real code emitted; in general, users can count on structs being copied whenever necessary to preserve value semantics between different names. How would you suggest rewording the documentation?</div></div></blockquote></div><br class=""><div class="">Perhaps take a look at the Go language documentation for ideas, since it has similar semantics. Here’s an explanation I found in their FAQ:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><b class="">How do I know whether a variable is allocated on the heap or the stack?</b><br class=""><br class="">From a correctness standpoint, you don't need to know. Each variable in Go exists as long as there are references to it. The storage location chosen by the implementation is irrelevant to the semantics of the language.<br class=""><br class="">The storage location does have an effect on writing efficient programs. When possible, the Go compilers will allocate variables that are local to a function in that function's stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors. Also, if a local variable is very large, it might make more sense to store it on the heap rather than the stack.<br class=""><br class="">In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.<br class=""></blockquote></blockquote><br class=""><a href="https://golang.org/doc/faq#stack_or_heap" class="">https://golang.org/doc/faq#stack_or_heap</a></div><div class=""><br class=""></div><div class="">—Jens</div></body></html>