> On Jul 25, 2017, at 2:14 AM, Félix Cloutier via swift-evolution > <swift-evolution@swift.org> wrote: > > It seems to me that I'm the one advocating for fewer language changes, and > the majority of sub-features that are being requested here don't feel > particularly more general to me. > > In its current form, this proposal tackles a contentious syntax to declare > fixed-length arrays and a similarly contentious syntax to initialize them, it > has multi-dimensional arrays, unpacking of arrays as parameter lists, > zero-size types with alignment requirements, sized array literals, explicit > conversions between array types, rules for deterministic initialization, > vector types. Out of these, I could see parameter unpacking and vectors used > for more than fixed-size arrays. (I haven't been through the entire > discussion, though, so you might be able to point out a few more.)
On “unpacking of arrays as parameter lists,” are you talking about tuple conversion? That’s mainly to convert legacy C-conversions, which are manually homogenous tuples, to proper arrays. I added a little generalization instead of requiring a strict flat “(T, T, …, T, T)” format for the tuple type. If I didn’t need that legacy support, I probably wouldn’t have added tuple conversion at all. So zero-size arrays should have no alignment requirements? Looking at a playground, empty tuples (both “()” and “((), ())”) have zero size but a stride of 1. Since elements of an array are spaced out by stride instead of size, what happens if an empty array is used as an element type. Zero-size arrays should take up at least a stride of 1, but if not rounded up to the element type’s alignment, then the array alignment won’t match the element alignment. These worries are why I initially banned empty arrays from being element types. Should I go back to that? The proposal technically does not affect the rules for deterministic initialization. The only point of note is since FSAs are aggregate compound types, an instance's elements’ DI statuses are tracked separately, just like tuple members. Everything in the rest of that section, besides future suggestions, falls into place using the existing DI rules. Since FSAs are a new kind of type, new ABI entries need to be formed. A reason to mention vector mode now is that using a processor vector-unit type or not affects the implementation of a FSA, hence its ABI. I want to put all the parameters on FSA that could affect the ABI in at once, so we don’t have to propose another ABI change later. This definitely includes vector mode, and may include multi-dimensionality. > There's also a number of issues that aren't addressed in the document, which > I feel are obscured by the sheer number of things that it asks to consider: > for instance, as we mentioned on another thread, Swift anonymous types can't > conform to protocols, so it's not clear what fixed-size arrays have to be > under the hood to be iterable. Did you look over the document? There’s a whole section on element traversal. If you really want a Collection, and/or you want a Swift version of the “T[]” parameter interface from C where the argument can be an array of any length but a constant type, then use “withUnsafe(Mutable)Flattening”. If you want to iterate without converting to a Collection first, then you can use a FSA as the target of a “for-in” loop directly. If you need the iteration counter during the for-loop, a spiritual equivalent to Collection’s “enumerated," then use the new “#indexOf” primary expression. Iteration order of a FSA during a “for-in” loop is unspecified. That’s because I want to allow the compiler to pick what it thinks is the best order (which may not be storage order (but probably would be)). And I want to allow the compiler to use simultaneous (or other overlapping) orders. And that previous point is to allow processor vector-unit types as FSA implementations. > Of course, if you take all of that, that's possibly bigger than non-type > generic parameters, but I question whether it all needs to pass at the same > time, or even if there are things that could be dropped to make this more > manageable. I already have dropped some things. Not sure how much I can trim down and keep Version 1 of FSAs useable. — 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
