Issue 1323

[Daniel Gibson]

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).

Cheers,
- Daniel