Does D have too many features?

[Timon Gehr]

On 05/02/2012 04:01 PM, Andrei Alexandrescu wrote:
> 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
>
>

The interface is different:

void main(){
     int[] a = [0,0,0];
     a[2] = 3;
     assert(2 !in a);
}

vs.

void main(){
     int[int] aa;
     aa[2] = 3;
     assert(2 in aa);
}