On 10/08/2010 01:45 PM, Juanjo Alvarez wrote:
Pelle Wrote:
On 10/08/2010 03:18 AM, Juanjo Alvarez wrote:
On Thu, 7 Oct 2010 15:53:13 -0700, Jonathan M Davis
<jmdavisp...@gmx.com> wrote:
Except that when you're dealing with generic code which has to deal
with
multiple container types (like std.algorithm), you _need_ certain
complexity
guarantees about an operation since it could happen on any
container that it's
Then, don't use it in std.algorithm or any other code that needs
guaranteed complexity, just like now. I don't see the problem with a
generic "in" operator, nobody would be forced to use it.
What do you suggest for fast lookup in a container?
What is being used now? How can having "in" and not using it (just like now) in
functions requiring guaranteed complexity can be worse than not having it?
If I write a generic algorithm, I can use opIn and assume it is fast. If
I don't need the speed, I can use canFind over the container's range
instead. If we say opIn can be slow, the fast version goes away.
The only drawback I can see to having an "in" operator with all containers is
that some programmers would not read the documentation and use it expecting it to be
fast. But then that also happens with many other language constructs and some programmers
will write crappy algoritms anyway.
