<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div>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.</div><div><br class=""></div><div>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).</div><div><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jan 15, 2016, at 13:08, Jaden Geller wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">Jaden Geller</div><div class="">Sent from my iPhone</div><div class=""><br class="">On Jan 15, 2016, at 11:22 AM, Dave via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">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.<div class=""><br class=""></div><div class="">Which is not to say I’m against having this because it does sound handy, I just don’t want it <i class="">instead</i> of the current filter function.</div><div class=""><br class=""><div class="">
- Dave Sweeris
</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Jan 15, 2016, at 09:59, Arman Shan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 15, 2016, at 12:11 PM, Developer <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">If we're going to add a partition method, can the original filter be rewritten in terms of it?<br class=""><br class="">~Robert Widmann</div><div class=""><br class="">2016/01/15 12:07、Nate Birkholz via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">That seems like a solid idea.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jan 15, 2016 at 8:02 AM, Arman Shanjani via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><p class=""><span class="">Hi,</span></p><p class=""><span class="">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?</span></p><p class="">Thank you,</p><p class="">Arman</p></div>
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature">Nate Birkholz</div>
</div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></body></html>