> On Aug 1, 2017, at 1:03 PM, Tino Heth <2...@gmx.de> wrote: > >> Sequence/Collection have other problems fitting with fixed-size arrays. >> There needs to be a new set of more basic protocols that both arrays and >> Sequence or Collection can conform to. > 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). >> 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.) 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. >> 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. > 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. > [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. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
