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

[Tino Heth]

>> What exactly is the problem with Sequence that makes you believe there is need for a more basic protocol?
> 
> For one, the return value of map is wrong. Sequence.map returns an Array, since a Sequence may not be a container itself. Using Array may be a minor inconvenience for Collection. But it’s a huge surprise if a fixed-size array’s map doesn’t return another fixed-size array of the same shape (not necessarily the same element type).
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.

>>> Or to flip it, just use multi-dimensional arrays with one bound. Multi-dimensionality does not impose an implementation penalty
>> I'd call the (imho extremely) increased complexity and loosing conformance to Collection a heave penalty… actually, it would strip arrays of their biggest unique feature compared to tuples.
>> And after all, all arrays have to be mapped to a single dimension, so I don't see the ability to define an array with ten dimensions on the fly as a big win (because it's rather easy to derive such a type from a one-dimensional array).
> 
> I said that not even one-dimensional arrays can support Collection by default, so ripping out multi-dimensional support won’t bring Collection back for 1D arrays. (Before that I was going to support Collection for just 1D arrays, so keeping multi-dimensional support or not wouldn’t change.)
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.

> Anyway, withUnsafe(Mutable)Flattening would be available as a standard global function for your Collection needs. It just isn’t built into the array types.
So people should get used to use an "unsafe" method for basic tasks like iteration?

>>> Wrapping multi-dimensionality in a type would forfeit it being a compound type, which would forfeit piecemeal initialization.
>> [Basic question: What definition of compound type are you referring to?]
> 
> Compound types: functions and tuples. Versus named types: structures, classes, and enumerations.
[never seen functions classified as a compound type, but that doesn't matter here]

>> Why would there be a fundamental difference in initialisation between an array, and an object that holds an array and maps to its contents?
> 
> A tuple can have its members initialized in piecemeal and still satisfy deterministic initialization. The named types need to do all their sub-objects' initializations before any designated initializer ends. I want the former for array instances, not the latter. It’s important for numeric applications, so math arrays don’t have to be set twice, once for an arbitrary default and again for the real data.

let f: Array<Float, size: 3> = [0, 9.81, 0]
Where's f filled with arbitrary default?

>> [ah, I think I got that point: It's not about leaving parts uninitialised and taking care of them later, but the ability to use literals like
>> [[[0, 0, 1], [0, 1, 0]], [0, 0, 2], [0, 2, 0]]]
>> right?]
> 
> It is about delaying initializations. But I don’t know what you mean about your statement about literals.
Then I've no clue what you want to achieve; can you give an example in pseudocode?

- Tino
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170801/7361ee08/attachment.html>