"in" everywhere

[Juanjo Alvarez]

Steven Schveighoffer Wrote:

> On Thu, 07 Oct 2010 21:18:56 -0400, Juanjo Alvarez <fake at fakeemail.com>  
> 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.
> 
> That kind of "documentation" is useless, it doesn't prevent use, and it  
> doesn't feel right to the person who accidentally uses it.  When I call
> 
> sort(x);
> 
> and it performs horribly, am I going to blame x or sort?  Certainly, I'll  
> never think it's my own fault :)
> 
> -Steve

True! And that's the only drawback I see on generalizing "in", but there are many things in programming languages that doesn't feel right when you don't
know the language well. That doesn't mean that D should be the "programming for dummies on rails with a constant automated tutor included" language; if I 
read well the site, it is mean to be a practical language with the ability to shot yourself in the foot.

Still, I don't understand how generalizing "in" could affect std.algorithm et al if they only use "in" for AAs, just like now.