<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 Jul 31, 2017, at 11:09 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" style="font-family: AvenirNext-Regular; font-size: 14px; 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=""><br class="Apple-interchange-newline">On Mon, Jul 31, 2017 at 02:51 Gor Gyolchanyan <<a href="mailto:gor.f.gyolchanyan@icloud.com" class="">gor.f.gyolchanyan@icloud.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="font-family: AvenirNext-Regular; font-size: 14px; 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; margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 31, 2017, at 10:40 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_6462217509234542158Apple-interchange-newline"><div class=""><div dir="auto" style="font-family: AvenirNext-Regular; font-size: 14px; 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;" class=""><br class="m_6462217509234542158Apple-interchange-newline">On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="font-family: AvenirNext-Regular; font-size: 14px; 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; 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" style="font-family: AvenirNext-Regular; font-size: 14px; 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;" class=""><br class=""></div><div dir="auto" style="font-family: AvenirNext-Regular; font-size: 14px; 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;" 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></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class="">Because the compiler shouldn't know what an array is (that is, what a Swift array is, not the C array that LLVM has a primitive type for).</div></div></div></blockquote><div dir="auto" style="font-family: AvenirNext-Regular; font-size: 14px; 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=""><br class=""></div><div dir="auto" style="font-family: AvenirNext-Regular; font-size: 14px; 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="">Wait, why not? It already does, afaict, just as it knows about integers, strings, etc. In fact, as I understand it, one dividing line between the standard library and Foundation is whether or not a type needs compiler knowledge of it.</div><div dir="auto" style="font-family: AvenirNext-Regular; font-size: 14px; 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=""><br class=""></div><blockquote class="gmail_quote" style="font-family: AvenirNext-Regular; font-size: 14px; 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; margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class="">And if the compiler doesn't know what an array is and what resizing means, then the array has to define that optimization hint itself, which will either involve new syntax for attaching metadata for declarative special-case solutions. Besides, it won't be getting the full benefits of fixed-sized arrays. The biggest benefit of fixed-size arrays is allocation cost (which is exactly zero for static fixed-sized arrays and a single clock cycle for unescaped local fixed-sized arrays), which is not going to improve if an array is simply forbidden from resizing.</div></div></div></blockquote><div dir="auto" style="font-family: AvenirNext-Regular; font-size: 14px; 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=""><br class=""></div><div dir="auto" style="font-family: AvenirNext-Regular; font-size: 14px; 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="">I'm not speaking about under the hood; I'm speaking about spelling:</div><div dir="auto" style="font-family: AvenirNext-Regular; font-size: 14px; 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=""><br class=""></div><div dir="auto" style="font-family: AvenirNext-Regular; font-size: 14px; 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="">let foo: [Int] = [1, 2, 3] // this clearly needs no resizing</div><div dir="auto" style="font-family: AvenirNext-Regular; font-size: 14px; 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="">var bar: [Int] = [1, 2, 3] // not clear if this needs resizing</div><div dir="auto" style="font-family: AvenirNext-Regular; font-size: 14px; 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="">var baz: fixed [Int] = [1, 2, 3] // allow the user to tell the compiler</div></div></blockquote><div><br class=""></div><div>If a simple compiler hint is what you mean, then I'd go for something less array-centric and more along the lines of "arbitrary compiler hint", much like how C preprocessor has pragmas.</div><div>I'd go for this syntax instead:</div><div><br class=""></div><div>var baz: @hint(fixed) Int = [1, 2, 3]</div><div><br class=""></div><div>Which has the added benefit of prepping the general syntax for any other part of the language where the compiler could use a little hand-holding from the human.</div><div>I didn't want it to be simply @fixed, because the singular attributes so far follow the pattern of being mandatory, rather than optional hints, so that we don't confuse people by having at attribute that may or may not actually do anything and reserve that to a single very specific attribute.</div><div><br class=""></div><div>But this is all outside of the topic.</div><div><br class=""></div><div>Within the topic there were two major points made regarding compile-time evaluation:</div><div>* It's not warranted to consider this unless actual use cases are brought forth.</div><div>* Many of those use cases can be solved at run-time (e.g. generic value parameters).</div><div><br class=""></div><div>My counter-point to those are:</div><div>* It's always possible to do things at run-time. I think it isn't worth spending time implementing a feature and complicating the language if it won't provide enough performance and convenience gains.</div><div>* Many of the features discussed here (including generic value parameters and fixed-size arrays) would be much simpler, more convenient, more performant and more powerful if the underlying deal-breaking lack of compile-time facilities was remedied.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" style="font-family: AvenirNext-Regular; font-size: 14px; 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="">Under the hood, Swift optimizes as best it can.</div><div dir="auto" style="font-family: AvenirNext-Regular; font-size: 14px; 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=""><br class=""></div><blockquote class="gmail_quote" style="font-family: AvenirNext-Regular; font-size: 14px; 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; margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><div class=""></div><div class="">For really fast storage, Clang has __builtin_alloca, which could be wrapped in an __attribute__((__always_inline__)) function and exposed to Swift.</div><div class="">For semantically non-resizable arrays, we can simply implement a FixedSizeArray with no changes to the language.</div><div class="">Considering these options, I don't think solving the use case of fixed-size arrays is worth complicating the language.</div><div class="">This is why I'm pushing for elaborate compile-time execution feature. It won't solve a specific use-case, it will solve a very wide domain of use cases.</div></div></div><div style="word-wrap: break-word;" class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><blockquote class="gmail_quote" style="font-family: AvenirNext-Regular; font-size: 14px; 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; margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">As far as I know, the pinnacle of uses for fixed-size arrays is having a compile-time pre-allocated space of the necessary size (either literally at compile-time if that's a static variable, or added to the pre-computed offset of the stack pointer in case of a local variable).<br class=""><br class="">> Value equality would still affect the type-checker, but I think we could pretty easily just say that all bound expressions are assumed to potentially resolve unequally unless they are literals or references to the same 'let' constant.<br class=""><br class="">Shouldn't the type-checker use the Equatable protocol conformance to test for equality? Moreover, as far as I know, Equatable is not recognized by the compiler in any way, so it's just a regular protocol. What would make it special? Some types would implement operator == to compare themselves to other types, that's beyond the scope of Equatable. What about those? And how are custom operator implementations going to serve this purpose at compile-time? Or will it just ignore the semantics of the type and reduce it to a sequence of bits? Or maybe only a few hand-picked types will be supported?<br class=""><br class="">The seemingly simple generic value parameter concept gets vastly complicated and/or poorly designed without an elaborate compile-time execution system... Unless I'm missing an obvious way out.<br class=""><br class="">> The only hard constraint is that types need to be consistent, but that just means that we need to have a model in which bound expressions are evaluated exactly once at runtime (and of course typically folded at compile time).<br class=""><br class="">What exactly would it take to be able to execute select piece of code at compile-time? Taking the AST, converting it to LLVM IR and feeding it to the MCJIT engine seems to be easy enough. But I'm pretty sure it's more tricky than that. Is there a special assumption or two made about the code that prevents this from happening?<br class=""><br class="">> John.<br class="">><br class="">>> Or do you mean that the bounds are integer literals? (That's what I have in the design document now.)<br class="">>><br class="">>> Sent from my iPhone<br class="">>><br class="">>> On Jul 30, 2017, at 8:51 PM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>> wrote:<br class="">>><br class="">>>>> On Jul 29, 2017, at 7:01 PM, Daryle Walker via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">>>>> The “constexpr” facility from C++ allows users to define constants and functions that are determined and usable at compile-time, for compile-time constructs but still usable at run-time. The facility is a key step for value-based generic parameters (and fixed-size arrays if you don’t want to be stuck with integer literals for bounds). Can figuring out Swift’s story here be part of Swift 5?<br class="">>>><br class="">>>> Note that there's no particular reason that value-based generic parameters, including fixed-size arrays, actually need to be constant expressions in Swift.<br class="">>>><br class="">>>> John.<br class="">><br class="">> _______________________________________________<br class="">> swift-evolution mailing list<br class="">><span class="m_6462217509234542158Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">><span class="m_6462217509234542158Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></div></blockquote></div></div></blockquote></div></blockquote></div><br class=""></body></html>