<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 12, 2017, at 9:09 PM, Daryle Walker <<a href="mailto:darylew@mac.com" class="">darylew@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Jul 12, 2017, at 4:05 PM, Robert Widmann <<a href="mailto:rwidmann@apple.com" class="">rwidmann@apple.com</a>> wrote:<br class=""><br class="">I think this proposal is trying to do too much at once. 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><br class=""></div><div>“Sugar” means an equivalent way to spell something concrete, but here there is nothing concrete. 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”. 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><br class=""></div><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><br class=""></div><div><font face="Menlo" class="">var b: [_, _] = [3.14159, 2.71828]</font></div><div><br class=""></div><div>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><br class=""></div><div><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><br class=""></div><div>As long as you have this magical type, you should probably give it some magical methods. A “backfill” initializer, perhaps. We cannot break DI just because it’s syntactically inconvenient.</div><div><br class=""></div><div>You’ve also stumbled onto the notion of a “reasonable default”, which for a language with a rich type system is a farce. 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 <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><br class=""></div><div>You must define these semantics. We cannot hand-wave about something so massively complicated. For one, I don’t know what “automatically determined” in regards to a non-referentially-transparent language means.</div><br 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><br class=""></div><div>See above. 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><br class=""></div><div>We control the import of those “tuples", so we could switch them to be imported as your new type. If you can make your proposal function in a backwards-compatible manner we wouldn’t need this.</div><br 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><br class="">— <br class="">Daryle Walker<br class="">Mac, Internet, and Video Game Junkie<br class="">darylew AT mac DOT com <br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>