"in" everywhere

[so]

On Fri, 08 Oct 2010 14:58:27 +0300, Steven Schveighoffer  
<schveiguy at yahoo.com> 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

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/