[swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker]

> On Aug 3, 2017, at 7:20 AM, Tino Heth <2th at gmx.de> wrote:
> 
> Hi Daryle,
> 
> I think we agree a lot on the importance of fixed-size arrays, but have a different opinion on which aspect is the most valuable… (so we now only have to agree that mine is better ;-) ;-)
> My motivation for FSA is safety and convenience:
> I want to iterate over C arrays in a straightforward way, but primarily, I don't want to accidentally multiply a vector of size 3 with a 2×2 matrix.

Data modeling is important for me too. That’s why the proposal includes multi-dimensionality and why I didn’t just jam in Collection support. We don’t want to add conformance then find out that was a mistake.

> Of course, fast is cool, but I don't expect to suffer from bad performance because of implementation details like how, where and when memory allocation happens.
> Your focus, on the other hand, seems to be performance:
> You don't want to give guarantees about the order because of (hypothetical?) optimisations that could be blocked by that, and avoid initialisation overhead.

I also don’t want to block parallel/vector processing.

let a: @vector [4; Int] = //…
let b: @vector [4; Int] = //…
var c: @vector [4; Int] = //…
//…
loop: for i in a {
    c[ #indexOf(loop) ] = i * b[ #indexOf(loop) ]
}
//…

I want the compiler to potentially be able to see that the elements are being computed in formation and use vector-unit instructions instead of serial processing.

> You brought "withUnsafeFlattening" to the table to add convenience, but I think that is the wrong direction:
> Safe should be default, and it's quite common that you have to live with "unsafe" when you need "fast".

The name has “Unsafe” because the Collection type used, UnsafeBufferPointer, does. I don’t know enough about what makes the existing “Unsafe” API that way for the flattening function to declared “safe”. It could be safe for all I know.

A substitute Collection-access function besides “withUnsafeFlattening” would either copy the elements (i.e. be inefficient, especially for large arrays) or somehow secretly maintain a reference to the array in memory. The latter would then be “withUnsafeFlattening” with a prettier name.

My first reason for “withUnsafeFlattening” was to allow API to use any FSA of a given element type, no matter the shape.

> As you don't want to confirm to Sequence at all, it shouldn't bother you if the iterator sacrifices a tiny bit of performance in exchange for a reliable order, and when you really need piecemeal initialisation, you could take a FSA-Variant that skips initialisation of elements.
> Of course, that wouldn't be ideal, and there should be an "Unsafe" in the name of that type — but I don't think tuple-like delayed initialisation would help when solving real-world problems:
> The "x.0 = 0; x.1 = 1" case is trivial and can be done with normal init, and when this isn't enough, you most likely loose all guarantees because you use a loop to fill that array*.

Using a loop for array initialization is why I suggested we should look into run-time DI, which should be kept to restricted circumstances.

> I really appreciate the effort you spend for digging into the low-level details, and hope that we end up with a draft that satisfies your use case.
> 
> - Tino
> 
> * There are actually cases where you want to compute the value of one element based on another one, but that might as well be an indicator that you are better off with a tuple, instead of using an array.
> 
>>> So would you say Dictionary shouldn't conform to Collection either?
>>> Just because a type conforms to a protocol doesn't mean it can't add its own methods on top.
>> 
>> But the FSA interface and the Sequence/Collection interface would be very similar, basically competing, leading to a schizophrenic interface. Since another part of the overall FSA interface implements Collection, just use that.
> Yes, I can't argue against the claim that Collection sometimes feels a little bit odd :-( — but it is what it is, and maybe there will be improvements in the future that could take into account the experience with FSA.
> 
>>> Swift has one-dimensional arrays, and they support Collection... this may sound like nitpicking that only works because there is no explicit "fixed-size" in you statement, but feel free to prove me wrong for FSAs.
>> 
>> Yes, I meant FSAs, not both them and Array; it’s long-winded to keep adding the “fixed-size” part.
> So we do agree that there is no fundamental reason that stops FSAs from being collections? ;-)

Besides that they can’t be Sequences, unless you throw away allowing parallel/vector processing in the future. (That can’t be bolted onto Version 2, since committing to Sequence means you committed to single-thread iteration.) Just found out that C++ 17 (optionally) adds parallel/vector processing to its for-loops. I guess I caught on to a trend.

— 
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/20170806/4dbe948e/attachment.html>