Do you find this significantly clearer at the point of use than the existing repeating: init? It's not really obvious to me what the win is. (To be clear, I'm also not really opposed, but this seems like a very minor improvement at first glance).
Collection types, mainly, but element types would also be interesting here.
What I personally would like to see is a few well-motivated examples of this in use, with a comparison to what it would look like using the existing T(repeating: 0, count: n).
Also, this can be defined for all RRCs, but does the naming and functionality make sense for all of them, or should it be more narrowly constrained? Should Data have a .zeros(count:), for example?
w.r.t. element types I'm particularly interested in why you want to target AdditiveArithmetic instead of Numeric. Do you expect to use this initializer on, e.g. an Array of TensorFlow ShapedArrays?
Array or custom wrappers around split collections (similar to DSPSplitComplex). I might have more than just complex array, maybe I have a quaternion array (where each dimension is a single 1D array).
struct ComplexArray {
var real: [Double]
var imag: [Double]
var split: DSPDoubleSplitComplex
}
Also, this can be defined for all RRCs, but does the naming and functionality make sense for all of them, or should it be more narrowly constrained? Should Data have a .zeros(count:) , for example?
I think it make sense only as an extension on collections of AdditiveArithmetic.
w.r.t. element types I'm particularly interested in why you want to target AdditiveArithmetic instead of Numeric . Do you expect to use this initializer on, e.g. an Array of TensorFlow ShapedArray s?
AdditiveArithmetic makes the most sense. Would you be more in favor of this if this were on Numeric?
My first impulse would be to constrain it to Element: ExpressibleByIntegerLiteral, but I think one can make arguments for either Numeric or AdditiveArithmetic.
My question about RRC or something narrower is well explained by Data, which is an RRC with an element type of UInt8, so any of the element restrictions would let you do:
let x = Data(zeros: 15)
This is well defined, but not obviously useful or desired. It might make more sense to restrict the collection requirement further.
I feel like ExpressibleByIntegerLiteral is somewhat orthogonal to my needs. I find myself reaching for .zero quite a bit, it corresponds to C++ default constructible which is inspired by Alexander Stepanov's ideas, I believe.
I agree with Data, that is a somewhat strange consequence. It's the same as Data(count: ) fundamentally.