"in" everywhere

[Pelle]

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
>>> <jmdavisProg at 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.