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