Steven Schveighoffer Wrote: > On Thu, 07 Oct 2010 21:18:56 -0400, Juanjo Alvarez <f...@fakeemail.com> > 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. > > 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.
