Daniel Gibson napisał: > 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?
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