Issue 1323

[Jonathan M Davis]

On Saturday 08 January 2011 18:10:01 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)"

Probably. Shamefully, if I'm not careful, I tend to mix those up if I don't look 
them up. Regardless, it's whatever the complexity is to access a node on a 
balanced, binary tree.

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

Something like that. I'd have to look at the discussion again to know exactly 
how it all went, but it was definitely the outcome that we're not going to have 
opIn on built-in arrays.

- Jonathan M Davis