> Le 29 juil. 2017 à 16:01, Daryle Walker <dary...@mac.com> a écrit : > > >> 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.
No, I am talking about the `b[ [;1, 4] ]` syntax. > 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. I was merely enumerating the entirety of the features that your proposal requires to be implemented, as a response to Tino saying that I was suggesting more features that were less general. > 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. Yes, there is a section on array traversal, but there is a difference between saying "this needs to work" and "here's how it's going to work". If you're looking for what I missed, that would be that fixed-size arrays are meant to be their own special category of types, and not sugar on top of something else. Speaking of things that are not addressed in the document, then, would be what any of this looks like at the SIL level. In fact, your proposal never spells out "SIL". > 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”. We can already essentially do that with tuples. In fact, that's the current workaround for C arrays. Do you have code that currently tries to do C interop with fixed-size arrays? Have you identified pain points with that existing Swift code that you would like to make better with your fixed-size array proposal? Or is helping C interop only a secondary goal? > 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. It is my humble opinion that fixed-size arrays lose a lot of their usefulness if they can't at least be treated as Sequences. > 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. Why should fixed-size arrays have this special behavior over normal arrays? I find it hard to justify that fixed-size arrays iterate fundamentally differently from both variable-sized arrays in Swift and fixed-size arrays in C. I also don't see why the unspecified faster iteration algorithm could fundamentally only apply to fixed-size arrays. To me, that's a prime example of something that could be dropped. Félix _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
