[swift-evolution] Yet another fixed-size array spitball session

[Daryle Walker]

> On Jun 2, 2017, at 10:26 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> on Fri Jun 02 2017, Brent Royal-Gordon <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>>> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution
>>> <swift-evolution at swift.org> 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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170604/e231da5a/attachment.html>