> On Jul 31, 2017, at 9:54 PM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > On Mon, Jul 31, 2017 at 11:45 AM, Félix Cloutier <[email protected] > <mailto:[email protected]>> wrote: > >> Sure, and hence my point: suppose now `foo` is a function in the stdlib, and >> the stdlib authors have annotated the function so that it is `func foo(arr: >> fixed [Int])`. Then, any user who writes `var array = ...` could benefit >> from a performance boost because the compiler will not longer have to be >> pessimistic about copying in order to maintain COW semantics. This is why I >> made an explicit analogy to the design proposed for ownership in Swift, >> where end users don't have to understand it in order to benefit from the >> feature because the functions they call can give sufficiently important >> hints to help the compiler avoid unnecessary copying. >> >> I don't think that you claimed that this should be a solution to the >> fixed-size array problem, but just in case, also note that it's not. We >> can't make any [Int] layout-compatible with C fixed-size arrays because the >> length has to be encoded in the type (as it cannot be encoded in the data >> itself). >> >> I don't understand this point. Can you elaborate on what you mean here? Why >> does it have to be layout-compatible? > > > Then it seems that I have stricter requirements for fixed-size arrays than > you do, and I'd be curious to hear what you want to get out of fixed-size > arrays. If we compare a hypothetical `fixed [int]` to a hypothetical > `FixedSizeArray<T, N>`, these are some of the things that matter to me which > `fixed` can't offer: > > It doesn't allow you to specify the size of the array, it's just a promise > that the array is some immutable size. For instance, a `fixed [CGFloat]` > would be a terrible type to represent a vector, but a FixedSizeArray<CGFloat, > 4> would be appropriate, at least for the backing storage. A raw tuple would > be a poor choice because dynamically indexing into them is painful. > > Shouldn't this be solved by improvements to tuples? It's a highly desired > feature (by me and at least a few others) to allow tuples to conform to > protocols, whether fixed-size arrays are added or not. I expect that > conforming homogeneous tuples to Collection and enabling subscripting is > simply a matter of time.
I disagree; it seems to me that a homogeneous fixed-size sequence is its own concept, and there isn't any natural link between that concept and that of a tuple. The elements of a tuple are independent with no naturally-implied relationship; or put another way, tuple indices are nominal, not ordinal. Importing C arrays as tuples is a big old hack that has never really worked out well. John. > `fixed` is only useful when the compiler can determine the size of the array > statically. This makes it mostly useless as a storage qualifier if you > received the array as a parameter (*even* if you received a `fixed` array), > because you know that it has a constant size but you don't know what that > size is. > Therefore, using a fixed-size array as a generic parameter (crucially, such > as `fixed [fixed [Int]]`) is unlikely to work. > Even if that semantic hurdle is overcome, we'd still have no idea how much > memory to allocate for the outer array's buffer to make it work. > > As John McCall has replied, the array's bounds don't need to be statically > known for fixed-size arrays to have benefits. > > Even if `fixed [fixed [Int]]` could work, then each inner array could still > have a different size, which is almost certainly not what you intend by > nesting two fixed-size arrays. > > That's fair, but why at that point wouldn't you make your own Matrix type of > fixed size, which uses an Array of fixed size as the underlying storage? > > Layout compatibility is important if you want to use fixed-size arrays to > replace the clunky tuples that currently represent fixed-size arrays in > structs exported from C (which is probably my one single biggest motivation > for fixed-size arrays). You can't achieve layout compatibility if the size is > part of the data instead of part of the type. > > For me, that's an anti-goal, as IMO tuples are the most sensible way of > bridging a lot of these fixed-size arrays from C. Quite simply, I'd argue > that the most idiomatic way to represent four CGFloat instances is `(CGFloat, > CGFloat, CGFloat, CGFloat)`. The solution to certain operations being clunky > with tuples is to improve the ergonomics of tuples. For instance, if we need > a shorthand to avoid typing all those `CGFloat`s, then add one: `(4 * > CGFloat)`. If we need subscripting, then add it. > > Besides, attaching fixed-size array semantics to an inherently variable-size > Array is awkward. For `fixed` to be effective, it needs to disable methods > that change the size of the array, or warn that you're using them. I don't > like the cross-concern impact: now a keyword needs to know about method > implementations to restrict them. It also has to work with extension methods > on the Array type, and it shouldn't apply to just mutating functions because > mutations that don't change the length of the array are fine. > > The idea is that all facilities which would benefit from knowing that an > array is of a fixed count would opt into that benefit by indicating as such. > That is, all stdlib array methods that are guaranteed to preserve the size of > the array would be annotated as such. Again, by analogy to the ownership > manifesto's design where functions that take shared arguments could be > optimized on the basis of such annotation. The rest would fall out naturally. > > What would you use `fixed [Int]` for? Only as an optimization tool? > > Yes. > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
