<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="">Le 31 juil. 2017 à 00:40, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><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; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote"><div dir="auto" class=""><br class="Apple-interchange-newline">On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></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;">> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">><br class="">>> On Jul 30, 2017, at 11:43 PM, Daryle Walker <<a href="mailto:darylew@mac.com" target="_blank" class="">darylew@mac.com</a>> wrote:<br class="">>> The parameters for a fixed-size array type determine the type's size/stride, so how could the bounds not be needed during compile-time? The compiler can't layout objects otherwise.<br class="">><br class="">> 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'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 class=""><br class="">Doesn't this defeat the purpose of generic value parameters? We might as well use a regular parameter if there's no compile-time evaluation involved. In that case, fixed-sized arrays will be useless, because they'll be normal arrays with resizing disabled.</blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">OTOH, if the compiler can prove that a local array is never resized, why *shouldn't* it get all the benefits of a fixed-sized array without having to use a special syntax? Put another way, why shouldn'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 class=""><br class=""></div><div class="">The optimization is defeated as soon as the storage buffer might escape, just like for closures. Consider this:</div><div class=""><br class=""></div><div class=""><div class=""></div><blockquote type="cite" class=""><div class="">func foo(arr: [Int])</div><div class=""><br class=""></div><div class="">var array = [1, 2, 3, 4]</div><div class="">foo(arr: array)</div><div class="">array[1] = 2</div></blockquote><br class=""></div><div class="">If `array` is "unrolled" 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'd rather not get into @escaping arrays.</div><div class=""><br class=""></div><div class="">I don'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's not. We can'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 class=""><br class=""></div><div class="">Félix</div></div><br class=""></body></html>