On 5/2/12 6:15 AM, Tobias Pankrath wrote:


No, it is not an O(1) operation, it is *close* to O(1) (as much sense
as that statement can make). I don't know why you associate any
particular complexity with 'in' in the first place. And I do think
we're crippling the language, considering Python (and probably other
languages) has had this feature since forever.

I'm seriously worried. It seems to me like we're trying to cater to
people who can't reason about the types in their program and the
complexities of performing various operations on them. Since when did
algorithmic complexity become a reason to take away syntax sugar?

+1

I do argee. opIn is handy for arrays, too. That the complexity would be
linear and thus it should be disallowed is not a valid argument in my
opinion, because with the exact same argument you could kick
std.algorithm.find out of phobos. It is just obvious to every trained
programmer that finding an element in an unordered list takes O(n).

The problem here is making complexity an implementation detail of a uniform interface (e.g. over hashes and linear containers). That is fail.

Andrei


Reply via email to