<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="">On Jul 13, 2017, at 1:28 PM, Robert Widmann &lt;<a href="mailto:rwidmann@apple.com" class="">rwidmann@apple.com</a>&gt; wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 12, 2017, at 9:09 PM, Daryle Walker &lt;<a href="mailto:darylew@mac.com" class="">darylew@mac.com</a>&gt; wrote:</div><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Jul 12, 2017, at 4:05 PM, Robert Widmann &lt;<a href="mailto:rwidmann@apple.com" class="">rwidmann@apple.com</a>&gt; wrote:<br class=""><br class="">I think this proposal is trying to do too much at once. &nbsp;Correct me if I’m wrong, but you’re proposing<br class=""><br class="">1) New sugar for fixed-length arrays without a corresponding stdlib declaration<br class=""></blockquote><br class="">IIUC, “sugar” means an easier way to use existing functionality, right? In this proposal, there is neither sugar nor a standard library declaration for the same reason: these arrays are a new primitive at the user and ABI levels, not a library type. What is the (existing since you mentioned sugar) primitive you’re expecting a library fixed-size array to be based on?<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">“Sugar” means an equivalent way to spell something concrete, but here there is nothing concrete. &nbsp;We’d be hard-coding a magical library type into the compiler which is something that, up to now, we have refrained from doing because it massively complicates type checking and forces us to compromise to work around “just this one corner case”. &nbsp; Our notion of a “primitive” is not the same as C and C++; Int, Float, String, these are all Standard Library types - that happen to be backed by compiler intrinsics in some cases.</div></div></div></div></blockquote><div><br class=""></div><div>I don’t mean fixed-size arrays are a type vs. Int / Float / String (i.e. primitive types), but a kind of type vs. class / struct / enum / tuple (i.e. type primitives). It’s a primitive because it cannot be implemented by existing features. It's why the proposal mentions bit-code representations and ABI changes instead of library ones (besides support).</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Obviously, this means arrays can’t be implemented until at least Swift 5.<br class=""><br class=""><blockquote type="cite" class="">2) Arity and type inference for literals<br class=""></blockquote><br class="">I don’t know what you mean by these.<br class=""></div></div></blockquote><br class=""></div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">var b: [_, _] = [3.14159, 2.71828]</font></div><div class=""><br class=""></div><div class="">On the syntactic side: underbar has a very specific meaning in this language, and “infer this type/arity” isn’t one of them.</div></div></div></blockquote><div><br class=""></div><div>I guessed this after I woke up this morning. A way around this would be a new (but similar) kind of literal. But we’ve already used up all the ASCII bracketing character pairs. And you see there’s problems reusing the square brackets that array- and dictionary-literals use. Maybe we can chord the square brackets with something else:</div><div><br class=""></div><div>#[1, 2, 3, 4]# &nbsp;// [4: Int]</div><div>#[6; 1, 2, 3, 4]# &nbsp;// [6: Int], last two elements to be initialized later</div><div>#[6; “a", “b", “c", “d", default: “k"]# &nbsp;// [6: String], all elements initialized, need semicolon since the comma and colon are already used</div><div>#[6; 0: “a", 2: “c", 1: “b", 3: “d", default: “k"]# &nbsp;// [6: String], with specific indexes assigned per element initializer</div><div>#[2, 2; #[0, 0]#: 1, #[0, 1]#: 2, #[1, 0#]: 3, #[1, 1]#: 4]# &nbsp;// [2, 2: Int], this form gets long really fast, maybe use the closure version</div><div>#[1, 2, 3, 4]# as [2, 2: Int] &nbsp;// Reshaping uses less text</div><div>#[0;]# &nbsp;// Empty array</div><div>#[]# &nbsp;// Also empty array, can be used a shortcut initializer for any FSA to indicate no elements initially initialized</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">3) Default initialization semantics for arrays including a DI exception for fixed-length arrays that aren’t fully initialized <br class=""></blockquote><br class="">My first thought was full initialization, like other objects, but someone on the list really wanted a way to not have full initialization. I could see his point; filling in a bunch of zeros for a large array for math purposes could get expensive, especially if the values are immediately ran over. Even if we make closure-initialization return non-optionals, we still have to worry when an array is filled by a loop that gets exited early.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">As long as you have this magical type, you should probably give it some magical methods. &nbsp;A “backfill” initializer, perhaps. &nbsp;We cannot break DI just because it’s syntactically inconvenient.</div><div class=""><br class=""></div></div></div></div></blockquote><div><br class=""></div><div>There’s already the “default” term in extended array literals. And the “func” term allows the elements to be determined via closure.</div><div><br class=""></div><div>For DI, it’s worse than you think, which is why I put out a separate post on this issue. DI assumes one sub-declaration per sub-object; the raison de-tere for arrays is to defeat this assumption. DI and FSAs are fundamentally incompatible; something has to break (forced initialization on declaration, static array indexing, run-time DI, or undefined behavior on possible uninitialized reads).</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">You’ve also stumbled onto the notion of a “reasonable default”, which for a language with a rich type system is a farce. &nbsp;We can’t assume every type has some reasonable default that we can fill in automatically because many types don’t (for an extreme example, see&nbsp;<font face="Menlo" class="">Never</font>).</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">4) 2 new attribute declarations for unspecified concurrency semantics<br class=""></blockquote><br class="">Why not add some modern features relative to classic C? Or is it possible for these to be automatically determined (and carried out) by the compiler? I don’t think the vector-unit one can.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">You must define these semantics. &nbsp;We cannot hand-wave about something so massively complicated. &nbsp;For one, I don’t know what “automatically determined” in regards to a non-referentially-transparent language means.</div></div></div></div></blockquote><div><br class=""></div><div>I meant could the compiler see the code in the loop, determine there’s no cross-iteration dependencies (or other disqualifiers) and apply the effects of the “parallel” attribute automatically.</div><div><br class=""></div><div>I’m not a professional compiler writer, so I don’t know how much I have to specify and how much I can punt to the Swift developers to figure it out. If I have to do more on my side, I would appreciate help from actual compiler writers on what to put down.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">5) A magical compiler intrinsic that declares loop counters<br class=""></blockquote><br class="">Having the compiler figure out the best way to iterate an array seems a lot better than manually doing a bunch of loop and range calls, especially for multi-dimensional arrays. (I want one loop statement, no matter the number of dimensions.) But without those manual calls, you need some other way to determine your position in the loop.<br class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">See above. &nbsp;Auto-vectorization semantics are great, but we have to have them defined first.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">6) Static collection subtyping constraints referencing convertibility constraints we don’t currently have<br class=""></blockquote><br class="">I copied that from the section of the ABI document about tuples. We could drop it.<br class=""><br class=""><blockquote type="cite" class="">7) Tuple conversions<br class=""></blockquote><br class="">Since these arrays will replace manually homogenous tuples as the conversion for C arrays, we need a way to handle older code. I probably wouldn’t have bothered except for backwards compatibility.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">We control the import of those “tuples", so we could switch them to be imported as your new type. &nbsp;If you can make your proposal function in a backwards-compatible manner we wouldn’t need this.</div></div></div></div></blockquote><div><br class=""></div><div>New imports would use FSAs, but it wouldn’t be retroactive, so there needs to be a conversion between old C-array adaptations and the new ones. Unless you mean for translated C code to interact with newer Swift code, the C code would have to be re-adapted (which would swap out manually homogenous tuples for FSAs in the new source files)?</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Are manually homogenous tuples, with the multiplicity of the element type is specified with lexical repetition instead of a number, the sugar from point 1? If so, that use would be depreciated, not continued.<br class=""><br class=""><blockquote type="cite" class="">I believe your aims are noble, and this is certainly a tremendously important problem we need to solve, but I think there needs to be a measured response to the current state of things.<br class=""></blockquote></div></div></blockquote></div></div></div></blockquote></div><br class=""><div class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">—&nbsp;</div><div class="">Daryle Walker<br class="">Mac, Internet, and Video Game Junkie<br class="">darylew AT mac DOT com&nbsp;</div><div class=""><br class=""></div></div></div></div></body></html>