What's the deal with SortedRange
Steven Schveighoffer
schveiguy at gmail.com
Sun Apr 19 19:54:12 UTC 2020
This type has some annoying characteristics. Are these intentional? Are
they up for debate?
1. elem in sortedRange => bool, not typeof(elem)*. Why?
2. No access to input range, except via "release" which is a completely
ineffective mechanism to "ensure sortedness". Ways to circumvent:
a. r.save.release
b. r[0] = r[$-1];
c. r.sort!("a > b") (yes, this works).
d. just modify the original input data.
I find the "is this element in here, and if so, give me a reference"
mechanism you HAVE TO USE super super-annoying.
i.e. instead of if(auto ptr = elem in sortedRange) { /* use ptr */ }
you have to do:
auto eqr = sortedRange.equalRange(elem);
if(!eqr.empty) { /* use eqr.front */ }
Can we fix the API? I'd like to see `elem in r` become a pointer (if
possible). I'd also like to see a non-destructive way to get the input
as the "protections" against breaking sorting are so lacking that you
might as well make the type easier to use. Like maybe alias this the
input, and get rid of the release thing.
-Steve
More information about the Digitalmars-d
mailing list