[swift-evolution] Adding a new filter method which returns 2 arrays

davesweeris at mac.com davesweeris at mac.com
Fri Jan 15 16:26:31 CST 2016


That only works if the “infrastructure” storage doesn’t have to be in a specific location relative to the element storage. If so, then yes, you’re right. The elements of the one built from the end would be in reverse order, but that’s an entirely solvable problem, IMHO, either through a post-filtering reverse, or just by making the behavior clear in the API notes.

Or we could just not care… I’m not even sure this type of optimization makes a difference these days, with CPUs so often being instruction starved (although embedded and lower-end CPUs like the Core-M might not have as many cycles to spare, so maybe it does matter).

> On Jan 15, 2016, at 13:08, Jaden Geller wrote:
> 
> The total space necessary for both arrays will be exactly that of the original array (plus whatever constant space details need be stored about the array). Thus, the filter implementation could just move items to the front or the back of this contiguous storage space, and then return arrays backed by this storage. I don't necessarily think this level of optimization is necessary here, but it's definitely possible.
> 
> Jaden Geller
> Sent from my iPhone
> 
> On Jan 15, 2016, at 11:22 AM, Dave via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> I’m not sure if it’s currently done this way… In theory, filter can allocate enough contiguous memory to store all the results up front, skip all the overhead of expanding an array, and if it doesn’t all get used, well not caring (as much) about memory fragmentation is (one reason) why we have a 64-bit address space. This would be harder to do (or necessarily double the storage requirements) if filter could return two arrays, either of which could potentially contain as many elements as the original array.
>> 
>> Which is not to say I’m against having this because it does sound handy, I just don’t want it instead of the current filter function.
>> 
>> - Dave Sweeris
>> 
>>> On Jan 15, 2016, at 09:59, Arman Shan via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Yes. I was thinking we would just copy over the filter implementation, and it should only need a small modification to keep track of the items being filtered, and finally return 2 arrays.
>>> 
>>> 
>>>> On Jan 15, 2016, at 12:11 PM, Developer <devteam.codafi at gmail.com <mailto:devteam.codafi at gmail.com>> wrote:
>>>> 
>>>> If we're going to add a partition method, can the original filter be rewritten in terms of it?
>>>> 
>>>> ~Robert Widmann
>>>> 
>>>> 2016/01/15 12:07、Nate Birkholz via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> のメッセージ:
>>>> 
>>>>> That seems like a solid idea.
>>>>> 
>>>>> On Fri, Jan 15, 2016 at 8:02 AM, Arman Shanjani via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> Hi,
>>>>> 
>>>>> I was wondering if we could add a new filter method to the stdlib, where instead of returning just one array, it returns a tuple of 2 arrays, one with items that the closure returned true for and one with items that the closure returned false for. What do you think?
>>>>> 
>>>>> Thank you,
>>>>> 
>>>>> Arman
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Nate Birkholz
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/bdea9a3c/attachment.html>


More information about the swift-evolution mailing list