2010/10/8 Tomek Sowiński <j...@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?
