"in" everywhere

[Tomek Sowiński]

Daniel Gibson napisał:

> 2010/10/8 Tomek Sowiński <just at ask.me>:
>> bearophile napisał:
>>
>>> Another solution is to support the "in" operator for dynamic arrays too,
>>> and define a new attribute, like @complexity(), plus an Enum that allows
>>> to specify the worst case complexity. So associative arrays are
>>> annotated with @complexity(O.linear), while the function that searches
>>> for items/substrings in arrays/strings is @complexity(O.constant). At
>>> compile-time the generic code is then able to query the computational
>>> complexity of the "in" operator implementation. The problem is that the
>>> compiler today can't enforce functions annotated with
>>> @complexity(O.constant) to actually not perform a linear search (but I
>>> don't think it's a problem, today if the Range protocol asks an
>>> operation to not be worse than O(n ln n) the compiler doesn't enforce
>>> it).
>>
>> Good idea. It would make a nice use case for user-defined attributes in
>> D3. Making the language aware of @complexity specifically doesn't buy
>> much, all you need is:
>>
>> __traits(getAttribute, opIn, @complexity).bigOh == O.constant
>>
>> --
>> Tomek
>>
> 
> Doesn't the language have to be aware of this if it's supposed to work
> with ordinary arrays?

I don't think so, there can always be uniform syntax wrappers (there's already a bunch of 
them in std.array):

@complexity(O.constant)
size_t length(T[] arr) {
     return arr.length;
}

or special cases similar to hasLength!string.

-- 
Tomek