> On Aug 3, 2017, at 7:20 AM, Tino Heth <2...@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 

> 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 

swift-evolution mailing list

Reply via email to