"in" everywhere

[Stewart Gordon]

On 13/10/2010 21:11, Steven Schveighoffer wrote:
<snip>
> No, what is suggested is that we build the complexity guarantees into
> the interface. For example, if you had a List interface, and it could
> only guarantee O(n) performance for get, you'd call it e.g. slowGet(),
> to signify it's a slow operation, and define get to signify a fast
> operation. Similarly, 'in' is defined to be fast, so it has no business
> being a function on an array.
<snip>

And make get assert(false) if a fast get isn't implementable?  I think 
this is bug-prone - somebody may use it forgetting that it won't work on 
all List implementations, and then the algorithm will refuse at runtime 
to work at all rather than degrading gracefully to something that does.

But something else that would be useful is methods in the interface to 
tell which operations are fast and which are slow.

Stewart.