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

[Daryle Walker]

> On Aug 1, 2017, at 2:55 PM, Tino Heth <2th at gmx.de> wrote:
> 
>>> 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.

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.

>>>> 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.

Yes, I meant FSAs, not both them and Array; it’s long-winded to keep adding the “fixed-size” part.

> 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?

withUnsafeFlattening is not the main FSA iteration task; it’s still the for-loop. If you don’t care how traversal occurs, there’s no problem. Since FSAs are built-ins instead of library types, I want the compiler to have the freedom to determine its iteration method. If you care about a particular traversal path, then implement the looping manually; you shouldn’t be hoping that whatever order I’m convince to canonize happens to match your desired order (or use withUnsafeFlattening if you want storage order). If you manually loop not for the path order but to know the index, there’s the “#indexOf” expression as the equivalent to Sequence.enumerated().

But wait, wouldn’t storage order be the best order? Maybe, leaning towards yes, but there’s no reason to insist on it in case we’re wrong.

I’m not starting with Collection and trying to make FSAs fit, but starting from the other direction, and seeing how compatible the interfaces are.

> 
>>>> 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?

Your example has the all elements initialized in the literal, so it doesn’t matter here. But if you had 4 elements listed in the “size” part and kept the literal at 3 initializing values:

(1) “Array” here is a named type (class/struct/enum), so you violated DI in your initializer
(2) “Array” is a compound type although it looks like a named type. That’s confusing. (DI is satisfied as long as the last element is initialized before it, or the object as a whole, is read.)
[(3) “Array” is a type-alias to a more punctuator-soup-looking compound type. That’s legal, but still a little confusing.]

>>> [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?

My “delaying initializations” is the same as your “leaving parts uninitialized and taking care of them later.” I can’t give an example since you still haven’t explained what “but the ability to use literals…” means, so I can’t determine the contrast.

— 
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/20170803/309eb10f/attachment.html>