<div dir="ltr">Dave,<div><br></div><div>I've been giving this approach a lot of thought (and have read everything I've been able to find that you've written on the matter several times) and am not convinced it will work. Implementing a lowerBound function is trivial with a unary operator. However, implementing an upperBound or binarySearch function is, at least in my mind, a bit more difficult. The reason is because with the unary predicate we only know if an element is strictly less than the search value or greater than or equal to the search value, whereas in the standard approach we can determine strictly greater than as well as equivalence by swapping the inputs to the comp function.</div><div><br></div><div>For example, consider the set [2, 1, 5, 4]. If we want to search the set using a unary predicate for 3, we would pass in the closure { $0 < 3 }. I don't see how we can test for equivalence when all we know is "<" or ">=". With the standard approach using a binary predicate of `{ $0 < $1 }` we can use `{ $0 < 3 }` to get the lower bound and then `!{ 3 < $0 }` to get us to equivalence (or in this case, to return `false`).</div><div><br></div><div>Of course, an easy solution around this is to change the definition of the unary predicate to return a triple of values less/equal/greater. However, this would either require an additional datatype to the library (which I don't think is appropriate) OR require the user to increase the complexity of their predicate function to return -1/0/1. I don't think either of these are ideal or necessarily better than the standard approach of a value and a binary predicate.</div><div><br></div><div>I really like the idea of the unary predicate approach, I just can't seem to understand how it will work in practice. What am I missing here? (hopefully not something completely obvious!)</div><div><br></div><div>Thanks!</div><div>Jeff</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 24, 2016 at 4:52 PM, Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
on Tue Mar 15 2016, Nate Cook <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
>> On Mar 15, 2016, at 1:58 PM, Lorenzo Racca via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>>> On Mar 15, 2016, at 6:49 PM, Haravikk<br>
>>> <<a href="mailto:swift-evolution@haravikk.me">swift-evolution@haravikk.me</a><br>
>>> <mailto:<a href="mailto:swift-evolution@haravikk.me">swift-evolution@haravikk.me</a>>><br>
><br>
>>> wrote:<br>
>>><br>
>>>> On 15 Mar 2016, at 15:48, Lorenzo Racca <<a href="mailto:lorenzo.racca@live.it">lorenzo.racca@live.it</a> <mailto:<a href="mailto:lorenzo.racca@live.it">lorenzo.racca@live.it</a>>> wrote:<br>
>>>><br>
>>>> I already knew the impossibility of applying such a predicate as “$0 == 3” and I actually couldn’t quite figure out a solution.<br>
>>><br>
>>> I thought so, and I don’t think there is a way to do it, my point<br>
>>> was really just that your swift doc comments weren’t clear on that<br>
>>> point, then I went off at a bit of a tangent ;)<br>
>>><br>
>> No problem! What I am trying to figure out here is how we should<br>
>> implement the lowerBound and upperBound functions. Should they<br>
>> exactly reflect their C++ counterparts?<br>
>> Anyway, it seems all of our implementations have the same problem,<br>
>> that they cannot be univocally called with any predicate whatsoever,<br>
>> (or at least it seemed to me during some tests with the<br>
>> implementations :) ), so I don’t really know how we should act. I am<br>
>> a little blocked.<br>
>> Does anyone have ideas on how that could work no matter what predicate is given? Especially, an upperBound() function, which is a little trickier.<br>
><br>
> The key is to use a binary predicate (as used in sort and partition)<br>
> instead of a unary predicate. Then you can use the predicate as is for<br>
> lowerBound or with the arguments "reversed" for upperBound. The<br>
> methods would have a similar signature to indexOf—one that just takes<br>
> a value for comparable collections and one that takes a value and a<br>
> predicate.<br>
<br>
Having an overload that accepts a binary predicate is certainly a nice<br>
convenience, but the most general formulation takes a unary predicate<br>
that “partitions” the collection, i.e. returns false for the first N<br>
elements of the collection and returns true for the rest.<br>
<br>
IMO it's important to expose the unary predicate version. Lots of<br>
times, the thing you want to compare against doesn't have the same type<br>
as the elements of the collection. For example, you might have a<br>
collection of key-value pairs where you just want to compare against the<br>
keys, and you may not even be able to create an instance of the whole<br>
element. For more on this, see<br>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1313.html" rel="noreferrer" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1313.html</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Dave<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</font></span></blockquote></div><br></div>