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
