<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 1, 2017, at 3:21 AM, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><span 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; float: none; display: inline !important;" class="">FSAs intentionally don’t conform to Collection, because multi-dimensional arrays shouldn’t have to conform to a linear (by nature, hence the name “Sequence”) standard, at least by default.</span></div></blockquote></div>I strongly oppose and think it is a really bad idea:<div class="">Even if arrays are modelled multi-dimensional, there's always a canonical way to iterate through their elements, and this is an essential feature of this data type.</div></div></div></blockquote><div><br class=""></div><div>But linear access isn’t an inherent canonical property of multi-dimensional arrays, it’s just a consequence of arrays taking a contiguous block of memory (which is generally treated as linear in computers).</div><div><br class=""></div><div>Speaking of which, the “withUnsafe(Mutable)Flattening” functions give Collection access. (And it serves as an equivalent to the “T[]” function parameter interface from C.)</div><div><br class=""></div><div>I was going to support Collection for one-dimensional arrays, but I realized that would be a bad idea since that’s the dimensionality that would exploit vector-unit types the most. So you must convert first. (Well, the “conversion” to an Unsafe(Mutable)BufferPointer should just type-pun the address, unless the array was not initially in conventional addressable memory, which (small) objects aren’t by default in Swift, hence the “Unsafe” part of Swift’s pointer interface.)</div><div><br class=""></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="">Do you have any example for an existing optimisation that is important enough to cripple all fixed size arrays?</div><div class="">Those would not only be used to represent pixel buffers on a graphics card…</div></div></div></blockquote><div><br class=""></div><div>Sequence/Collection have other problems fitting with fixed-size arrays. There needs to be a new set of more basic protocols that both arrays and Sequence or Collection can conform to.</div><div><br class=""></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="">Also, if FSA have only one dimension (that's still my preference), all those issues are can be solved easily in the multidimensional structure build on top of the array.</div></div></div></blockquote><br class=""></div><div>Or to flip it, just use multi-dimensional arrays with one bound. Multi-dimensionality does not impose an implementation penalty, especially when declaring a one-dimensional array. Wrapping multi-dimensionality in a type would forfeit it being a compound type, which would forfeit piecemeal initialization. There’s no need for Swift arrays to be limited to C arrays plus Assignability (or be just C arrays plus Assignability plus Collection).</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="">— </div><div class="">Daryle Walker<br class="">Mac, Internet, and Video Game Junkie<br class="">darylew AT mac DOT com </div></div></div><br class=""><div><blockquote type="cite" class=""></blockquote></div></div></body></html>