<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 11:17 PM, Karl Wagner <span dir="ltr"><<a href="mailto:razielim@gmail.com" target="_blank">razielim@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><span class="gmail-"><blockquote type="cite"><div>On 4. Aug 2017, at 02:44, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail-m_7025132803659681101Apple-interchange-newline"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><span><div><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div><div style="overflow-wrap: break-word;"><div><br></div><div>The root cause, of course, is that the VLAs require new stack allocations each time, and the stack is only deallocated as one lump when the frame ends.</div></div></div></blockquote><div><br></div><div>That is true of alloca(), but not of VLAs. VLAs are freed when they go out of scope.</div><div><br></div></div></div></blockquote></div><br></span><div>Learned something today.</div><div><br></div><div>Anyway, if the goal is stack allocation, I would prefer that we explored other ways to achieve it before jumping to a new array-type. I’m not really a fan of a future where [3; Double] is one type and (Double, Double, Double) is something else, and Array<Double> is yet another thing.</div></div></blockquote><div><br></div><div>They are completely different things. <br><br></div><div>[3; Double] is three <i>contiguous</i> Doubles which may or may not live on the stack. <br><br></div><div>(Double, Double, Double) is three Doubles bound to a single variable <i>name</i>, which the compiler can rearrange for optimal performance and may or may not live on the stack. <br><br></div><div>Array<Double> is an vector of Doubles that can dynamically grow and always lives in the heap.<br></div><div> </div></div></div></div></div></blockquote><div><br></div></span><div>Yeah, I understand that — the problem I have is that I’m not sure it’s going to be obvious to everybody <i>else</i> when they should use which. We need to balance semantic purity against simplicity and ease-of-learning.</div><div><br></div><div>For example, I’m not sure many users are aware that tuple elements in Swift don’t have an ordered relationship; they certainly give that impression. This is especially confusing as "In mathematics a tuple is a finite ordered list (sequence) of elements.” [<a href="https://en.wikipedia.org/wiki/Tuple" target="_blank">https://en.wikipedia.org/<wbr>wiki/Tuple</a>]</div><span class="gmail-"><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div><div>From what I’ve read so far, the problem with stack-allocating some Array that you can pass to another function and which otherwise does not escape, is that the function may make an escaping reference (e.g. assigning it to an ivar or global, or capturing it in a closure).</div><div><br></div><div>How about if the compiler treated every Array it receives in a function as being potentially stack-allocated. The first time you capture it, it will check and copy to the heap if necessary. All subsequent escapes (including passing to other functions) use the Array known to be allocated on the heap, avoiding further checking or copying within the function.</div><div><br></div><div>The same goes for Dictionary, and really any arbitrary value-type with COW storage. The memory that those types allocate is part of the value, so it would be cool if we could treat it like that.</div></div>
<br></blockquote></div><br></div><div class="gmail_extra">This is not true. FSAs have nothing to do with automatic storage, their static size only makes them <i>eligible</i> to live on the stack, as tuples are now. The defining quality of FSAs is that they are static and contiguous. <br></div></div></div></blockquote><br></span></div><div>Really, the only <i>practical</i> difference between a FSA and a tuple is the memory layout. Do most users really need to care about that? For those users that do, wouldn’t an @-attribute be a less intrusive change to the language than a whole new list-style type?</div><div><br></div><div>For example, the benefit to having Collection-conforming tuples as our FSAs would be that they don’t necessarily have to be contiguous. If you have a large multi-dimensional list of Bools or some other tiny type, you might also <i>benefit</i> from those layout optimisations.</div><div><br></div><div>I like the simplicity in telling people:</div><div><br></div><div>- If you need a dynamically-sized list, use an Array</div><div>- If you need a fixed-sized list, use a tuple (and it will get an optimised layout. You can override this with an attribute, similar to @fixed_layout or @inlineable).</div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>- Karl</div></font></span></div></blockquote><div><br></div><div>Actually, if you do a lot of graphics programming like I do, the memory layout is very, <i>very</i> important. Swift may not care about layout, but many APIs that it interacts with do. <br><br></div><div>Is @fixed_layout actually planned to be part of the language? I was under the impression it’s just a placeholder attribute. Either way, I’d appreciate not having to write Float sixteen times for a 4x4 matrix type.<br></div><div><br></div></div><br></div></div>