> On Jul 12, 2017, at 4:05 PM, Robert Widmann <[email protected]> wrote: > > I think this proposal is trying to do too much at once. Correct me if I’m > wrong, but you’re proposing > > 1) New sugar for fixed-length arrays without a corresponding stdlib > declaration
IIUC, “sugar” means an easier way to use existing functionality, right? In this proposal, there is neither sugar nor a standard library declaration for the same reason: these arrays are a new primitive at the user and ABI levels, not a library type. What is the (existing since you mentioned sugar) primitive you’re expecting a library fixed-size array to be based on? Obviously, this means arrays can’t be implemented until at least Swift 5. > 2) Arity and type inference for literals I don’t know what you mean by these. > 3) Default initialization semantics for arrays including a DI exception for > fixed-length arrays that aren’t fully initialized My first thought was full initialization, like other objects, but someone on the list really wanted a way to not have full initialization. I could see his point; filling in a bunch of zeros for a large array for math purposes could get expensive, especially if the values are immediately ran over. Even if we make closure-initialization return non-optionals, we still have to worry when an array is filled by a loop that gets exited early. > 4) 2 new attribute declarations for unspecified concurrency semantics Why not add some modern features relative to classic C? Or is it possible for these to be automatically determined (and carried out) by the compiler? I don’t think the vector-unit one can. > 5) A magical compiler intrinsic that declares loop counters Having the compiler figure out the best way to iterate an array seems a lot better than manually doing a bunch of loop and range calls, especially for multi-dimensional arrays. (I want one loop statement, no matter the number of dimensions.) But without those manual calls, you need some other way to determine your position in the loop. > 6) Static collection subtyping constraints referencing convertibility > constraints we don’t currently have I copied that from the section of the ABI document about tuples. We could drop it. > 7) Tuple conversions Since these arrays will replace manually homogenous tuples as the conversion for C arrays, we need a way to handle older code. I probably wouldn’t have bothered except for backwards compatibility. Are manually homogenous tuples, with the multiplicity of the element type is specified with lexical repetition instead of a number, the sugar from point 1? If so, that use would be depreciated, not continued. > I believe your aims are noble, and this is certainly a tremendously important > problem we need to solve, but I think there needs to be a measured response > to the current state of things. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
