<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=""><div><blockquote type="cite" class=""><div class="">On Aug 6, 2017, at 11:59 PM, Daryle Walker &lt;<a href="mailto:darylew@mac.com" class="">darylew@mac.com</a>&gt; wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 1, 2017, at 2:58 PM, John McCall &lt;<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>&gt; wrote:</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=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Aug 1, 2017, at 9:53 AM, Daryle Walker &lt;<a href="mailto:darylew@mac.com" class="">darylew@mac.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="">On Jul 31, 2017, at 4:37 PM, Gor Gyolchanyan &lt;<a href="mailto:gor.f.gyolchanyan@icloud.com" class="">gor.f.gyolchanyan@icloud.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" 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;">Well, yeah, knowing its size statically is not a requirement, but having a guarantee of in-place allocation is. As long as non-escaped local fixed-size arrays live on the stack, I'm happy. 🙂</div></div></blockquote><br class=""></div><div class="">I was neutral on this, but after waking up I realized a problem. I want to use the LLVM type primitives to implement fixed-size arrays. Doing a run-time determination of layout and implementing it with alloca forfeits that (AFAIK). Unless the Swift run-time library comes with LLVM (which I doubt). Which means we do need compile-time constants after all.</div></div></div></blockquote><div class=""><br class=""></div>We are not going to design the Swift language around the goal of producing exact LLVM IR sequences. &nbsp;If you can't phrase this in real terms, it is irrelevant.</div></div></blockquote><br class=""></div><div class="">It isn’t being LLVM-specific, but for any similar system. The instruction generator has certain primitives, like 16-bit integers or 32-bit floats. LLVM (and probably rivals) also has aggregate primitives, heterogenous and homogenous (and the latter as standard and vector-unit). I want to use those primitives when possible. Saving sizing allocations until run-time, after it’s too late for sized-array-specific generated instructions, means that the array is probably implemented with general buffer pointer and length instructions. Any opportunities for IR-level optimization of the types is gone.</div></div></div></blockquote><div><br class=""></div></div><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">How often do you expect a statically sized array to need said size determined at run-time (with a function) versus a compile-time specification (with an integer literal or “constexpr” expression)? This may enable a 1% solution that anti-optimizes the 99% case.</div></div></div></blockquote><br class=""></div><div>If the array type is ultimately written with a constant bound, it will reliably end up having a constant static size for the same reason that (Either&lt;Int?, String&gt;, Float) has a constant static size despite tuples, optionals, and Either all being generic types: the compiler automatically does this sort of deep substitution when it's computing type layouts.</div><div><br class=""></div><div>Now, a generic method on all bounded array types would not know the size of 'self', for two reasons: it wouldn't know the bound, and it wouldn't know the layout of the element type. &nbsp;But of course we do have optimizations to generate specialized implementations of generic functions, and the specialized implementation would obviously be able to compute a static size of 'self' again. &nbsp;Moreover, a language design which required bounds to always be constant would only help this situation in an essentially trivial way: by outlawing such a method from being defined in the first place.</div><div><br class=""></div><div>John.</div><br class=""></body></html>