<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 31, 2017 at 3:39 AM, Félix Cloutier <span dir="ltr">&lt;<a href="mailto:felixcloutier@icloud.com" target="_blank">felixcloutier@icloud.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>Le 31 juil. 2017 à 00:40, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; a écrit :</div><br class="m_3831868753376035432Apple-interchange-newline"><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"><div class="gmail_quote"><div dir="auto"><br class="m_3831868753376035432Apple-interchange-newline">On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">&gt; On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>&gt;<br>&gt;&gt; On Jul 30, 2017, at 11:43 PM, Daryle Walker &lt;<a href="mailto:darylew@mac.com" target="_blank">darylew@mac.com</a>&gt; wrote:<br>&gt;&gt; The parameters for a fixed-size array type determine the type&#39;s size/stride, so how could the bounds not be needed during compile-time? The compiler can&#39;t layout objects otherwise.<br>&gt;<br>&gt; Swift is not C; it is perfectly capable of laying out objects at run time.  It already has to do that for generic types and types with resilient members.  That does, of course, have performance consequences, and those performance consequences might be unacceptable to you; but the fact that we can handle it means that we don&#39;t ultimately require a semantic concept of a constant expression, except inasmuch as we want to allow users to explicitly request guarantees about static layout.<br><br>Doesn&#39;t this defeat the purpose of generic value parameters? We might as well use a regular parameter if there&#39;s no compile-time evaluation involved. In that case, fixed-sized arrays will be useless, because they&#39;ll be normal arrays with resizing disabled.</blockquote><div dir="auto"><br></div><div dir="auto">OTOH, if the compiler can prove that a local array is never resized, why *shouldn&#39;t* it get all the benefits of a fixed-sized array without having to use a special syntax? Put another way, why shouldn&#39;t fixed-size be one of those optional attributes for arrays, like ownership will be for variables, that users can opt into for more performance but is otherwise automatically worked out by the compiler?</div></div></div></div></blockquote><div><br></div></span><div>The optimization is defeated as soon as the storage buffer might escape, just like for closures. Consider this:</div><div><br></div><div><div></div><blockquote type="cite"><div>func foo(arr: [Int])</div><div><br></div><div>var array = [1, 2, 3, 4]</div><div>foo(arr: array)</div><div>array[1] = 2</div></blockquote><br></div><div>If `array` is &quot;unrolled&quot; to the stack, and `foo` keeps a reference to the storage, then `array[1] = 2` has to pessimistically create a new storage buffer to maintain COW semantics. It could also leave a dangling reference to the buffer if the function returns before all of the other references are gone. I&#39;d rather not get into @escaping arrays.</div></div></div></blockquote><div><br></div><div>Sure, and hence my point: suppose now `foo` is a function in the stdlib, and the stdlib authors have annotated the function so that it is `func foo(arr: fixed [Int])`. Then, any user who writes `var array = ...` could benefit from a performance boost because the compiler will not longer have to be pessimistic about copying in order to maintain COW semantics. This is why I made an explicit analogy to the design proposed for ownership in Swift, where end users don&#39;t have to understand it in order to benefit from the feature because the functions they call can give sufficiently important hints to help the compiler avoid unnecessary copying.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>I don&#39;t think that you claimed that this should be a solution to the fixed-size array problem, but just in case, also note that it&#39;s not. We can&#39;t make any [Int] layout-compatible with C fixed-size arrays because the length has to be encoded in the type (as it cannot be encoded in the data itself).</div></div></div></blockquote><div><br></div><div>I don&#39;t understand this point. Can you elaborate on what you mean here? Why does it have to be layout-compatible?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class="HOEnZb"><font color="#888888"><div>Félix</div></font></span></div></div></blockquote></div><br></div></div>