>> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
