What's the deal with SortedRange

[Steven Schveighoffer]

On 4/19/20 10:33 PM, 9il wrote:
> On Sunday, 19 April 2020 at 21:06:41 UTC, Steven Schveighoffer wrote:
>> On 4/19/20 3:54 PM, Steven Schveighoffer wrote:
>>
>>> 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 */ }
>>
>> Another bug I just found. The above doesn't even work for my case.
>>
>> https://issues.dlang.org/show_bug.cgi?id=20751
>>
> 
> The following API is used for Mir [1]
>   - transitionIndex
>   - assumeSortedEqualIndex
>   - assumeSortedContains
> 
> The sorted range type looks to me like overengineering.

The nice thing is that the assumption that the data is sorted can be 
part of the type. So for instance, you can require a sorted range as a 
function parameter.

I don't think the idea of having a specific type for sorted data is 
overengineering, but the limitations are annoying and not fit for 
purpose anyway.

> Mir's Series [2] allows getting pointers,  but it is a sorted dictionary 
> composed of two arrays (keys and values). The "in" operator is always 
> @system because it can return null pointer. The safe alternative is 
> `tryGet`.

@safe code can return null pointers.

-Steve