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
