On Fri, 08 Oct 2010 14:58:27 +0300, Steven Schveighoffer
<schvei...@yahoo.com> 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
Sure, write some random strings and compile it, if it doesn't compile, you
can always blame Walter, right?
If documentation is useless, so is most of the programmers, you got to
accept it :)
Question is, should this affect compiler design? If you think it should,
you can't write a single line that calls "some other guy"'s code, it
doesn't matter if he use "in" or "out",
operators or just simple functions.
Thanks!
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
