.comp.lang.swift.evolution/15180>".
>
> If the `<=>` operator with a return type of a three-case `*enum* Order`,
> you can fully define the most generic versions of binary searches as:
>
> lowerBound(compare: Self.Collection.Element -> Order) -> Index
>
> e
Dave,
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
Nate - I suppose that's really the crux of the matter here. I agree a
binary predicate solves the problem, but is that the route we want to go? I
think it makes sense, but is there a reason we should stick with a unary
predicate? For some reason I had it in my mind that there was mention of
This is something I've been working on as well. The issue I've been stuck
on is how we define the predicate and match the definitions of lower_bound
and upper_bound from C++. It seems to me that the focus should be on these
implementations, since once we have these a simple binary_search follows.
