> On Jun 2, 2017, at 10:26 AM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > > on Fri Jun 02 2017, Brent Royal-Gordon <[email protected] > <mailto:[email protected]>> wrote: > >>> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution >>> <[email protected]> wrote: >>> >>> Static-Sized Arrays >> >> My preference would still be to build this from four separate features: >> >> 1. Magic tuple conformances: We already want to be able to >> automatically conform tuples to protocols like Equatable, Hashable, >> and Comparable. These can all be compiler magic; they don't have to be >> definable in userspace. >> >> 2. Conform tuples to Collection: The Element type should be the most >> specific common supertype of the tuple's elements. If all the elements >> are the same type, it would be that type. The Index and IndexDistance >> types should be Int. >> >> 3. Conform same-type tuples to MutableCollection: If all elements are >> the same type, you can also modify the values. (If their types vary in >> any way, however, it would not be safe to allow mutations, since you >> could assign the wrong type to an element.) >> >> 3. Add sugar for a tuple of N identical elements: Probably something >> like `4 * Int`, but opinions can vary.
Static-sized arrays should not be shoved into being a tuple with funny settings; that introduces subtleties into the tuple concept only because of jammed-in array support. The fact 3 separate-proposal-worthy features need to be introduced first, in which at least one is dubious in value (#2, since a lot of times the common type would be “Any”), should be a code smell on this approach. > I think any complete solution depends on at least two more things: > > 1. adding the ability to get an UnsafePointer to an immutable instance > of value type Do you mean something besides applying the address-of operator (I’m not sure what that is.) to “myArray.0”? What are you thinking of doing with such unsafe-pointers? In this thread, I had “array of T” or “[of T]” to make array-segment references, so you can make a function that can take an array of a certain type without specializing for each shape. (Worse, since we only have type-based generic parameters, we couldn’t generate such functions.) It’s the same as using “T[]” as a function parameter type in C. While thinking of this response, I looked at the same section of SwiftDoc.org <http://swiftdoc.org/> for UnsafePointer, and there were Unsafe(Mutable)BufferPointer. These types do the same job as my theoretical “[of T]”, so maybe I should defer to those. We would add a global function to convert given arrays to unsafe-buffer-pointers. > 2. support for leaving some of the elements uninitialized, or > alternatively, a variation of this type that is RangeReplaceable but > also bounded in capacity. AFAIK, all objects have to be fully initialized before the first read. If that’s the case, then skipping element initialization (which I can understand wanting when using a large array for a mathematical matrix type) would require a separate proposal, since we would need a full consideration of the consequences. (What happens when reading an uninitialized element?) For the variant, couldn’t that be implemented with a library type (since you need a per-object list of current elements), maybe using the base array type as a generic parameter. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
