[swift-evolution] Adding a new filter method which returns 2 arrays
Arman Shan
armanshan12 at gmail.com
Fri Jan 15 18:36:34 CST 2016
We could do it the easy way and just allocate 2 arrays of original size and return them.
We can also do the optimized way which isn't so user-friendly: make a new structure that contains an array and an index internally. The array will be the original array just "sorted" based on the predicate function. And the index is for where the second half starts. The public API would show 2 arrays somehow and gives the illusion that there are 2 arrays.
- Arman
On Jan 15, 2016, at 5:37 PM, Dave via swift-evolution <swift-evolution at swift.org> wrote:
>> On Jan 15, 2016, at 11:49, Arman Shan <armanshan12 at gmail.com> wrote:
>>
>> I definitely agree that this function should not replace the current filter function. We can give it a new name like "partition" or something.
> +1 on “partition”. That makes the semantics much clearer, IMHO.
>
>> Regarding the memory constraint: since both filter and partition methods will be provided, the developer may choose whether they prefer performance over memory fragmentation or not.
>>
>> Or maybe at the end of the partition method, if one of the result arrays is significantly smaller than the other, we copy the data into a smaller array and then return.
>
> Oh, yeah… I was thinking the excess storage would be deallocated at the end anyway. Honestly, this whole bit about super-optimizing the memory allocation assumes that the actual element storage is managed like C arrays (with a pointer to [0], and using pointer math to get the other elements) behind the scenes, and I don’t actually know that it’s done that way.
>
> - Dave Sweeris
>
> _______________________________________________
> 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/20160115/0cd42343/attachment.html>
More information about the swift-evolution
mailing list