Issue 1323

[Andrei Alexandrescu]

On 1/8/11 8:10 PM, Daniel Gibson wrote:
> Am 09.01.2011 03:03, schrieb Jonathan M Davis:
>> On Saturday 08 January 2011 16:19:21 bearophile wrote:
>>> BlazingWhitester:
>>>> If 'in' operator was overladable, users would expect it to have some
>>>> known complexity.
>>>
>>> Like O(n) for a linear search in an array.
>>
>> opIndex is supposed to be restricted to n log(n), I belive (the
>> complexity
>> necessary to access an element in a balanced, binary tree). It can
>> have lower
>> complexity - like O(1) - but it's not supposed to have higher
>> complexity. opIn
>> is effectively the operator for checking whether you can index the given
>> container with the given key/index. It's basically doing [key] and
>> telling you
>> whether it's there. So, it doesn't make sense that it would have lower
>> efficiency.
>>
>> This has been discussed before, and while some people would like to be
>> able to
>> use opIn at higher complexities, that's not the way that it's intended
>> to be
>> used, so we're not about to make it work that way for built-in arrays.
>>
>> - Jonathan M Davis
>
> "restricted to n log(n)"? I think you meant just "log(n)"
>
> As far as I remember the last discussion, it was considered to allow it
> for arrays of a constant size or with known (at compiletime) contents or
> something like that.
> But then again, that would feel kind of inconsistent (syntax is allowed
> for fixed size arrays but not for dynamic arrays).

But the reason is rock solid. Consistency is important, but it's not 
everything.

Oh, I just realized - we could have sortedRange define opIn_r!


Andrei