[swift-evolution] [Planning][Request] "constexpr" for Swift 5

John McCall rjmccall at apple.com
Mon Jul 31 22:47:26 CDT 2017


> On Jul 31, 2017, at 9:54 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> On Mon, Jul 31, 2017 at 11:45 AM, FĂ©lix Cloutier <felixcloutier at icloud.com <mailto:felixcloutier at icloud.com>> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170731/77e4933f/attachment.html>


More information about the swift-evolution mailing list