[Issue 20798] generic binarySearch (and others) should be available in std.algorithm
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Wed May 6 12:25:47 UTC 2020
https://issues.dlang.org/show_bug.cgi?id=20798
--- Comment #2 from Steven Schveighoffer <schveiguy at yahoo.com> ---
(In reply to ZombineDev from comment #1)
> So where does this approach fall short? Performance, convenience, and
> accessibility?
So for example, if I wanted the S values that had the field value 42, this does
not work. Instead I have to construct an S:
someArr
.equalRange(S("asd", 42))
.writeln;
Which isn't always easy or practical (S might be a large complicated struct,
with only constructors that require valid data for fields that I don't care
about).
In my code, I'm now doing:
auto idx = someArr.binarySearch!((S, v) => S.field < v)(val);
if(idx != someArr.length && someArr[idx].field == val) { /* use someArr[idx] */
}
This can be easily captured into a function (I know my values are unique so I
don't need to bother with an "equal range").
My contention is that I shouldn't have to write my own binarySearch function to
get this kind of functionality.
I suppose I could also do:
someArr
.map!(x => x.field)
.enumerate
.assumeSorted!((a, b) => a[1] < b[1])
.equalRange(tuple(0, 42))
.map!(a => someArr[a[0]])
.writeln;
But again, we are talking about a LOT of work, not only in range-transform
acrobatics, but in the compiler actually calling lots of intermediary
functions, just to do a simple search an already-sorted data.
A binary search is a simple base component that should be available for
constructing more complicated items. We shouldn't hide it inside SortedRange
with a very constrained set of interfaces.
--
More information about the Digitalmars-d-bugs
mailing list