This scored most:

>> 5) 'operator (a - b)' or 'operator (this - b)'.  (my vote: +0)  If I had to put in any new syntax I would prefer it to be this one.
>> 
>>     static Vector operator (a - b) (Vector a, Vector b);

And this did:

>> 1) Operators are normal, possibly virtual methods in classes, normal nonvirtual methods in structs (My vote: +1).
>> 
>>     Vector add (Vector b);

Now, the question is, what is "static" doing in the syntax? =)

One thing I dissagree with is the way you conducted this survay. Next time keep your opinions in a separate email please. Explain what you mean as much as you want, but don't optionate it. Otherwise you may effect the results of your replies.

I'm not trying to flame you, I'm just pointing this out for next time.

Whoops

"anderson" <anderson@firestar.com.au> wrote in message news:ajkvgl$h0k$1@digitaldaemon.com...
> One thing I dissagree with, is the way you conducted this survay. Next
time
> keep your opinions in a separate email please. Explain what you mean as
much
> as you want, but don't put opinions in it. Otherwise you may effect the
results
> of your replies.
>
> I'm not trying to flame you, I'm just pointing this out for next time.

Pavel Minayev wrote:

> On Fri, 16 Aug 2002 19:49:01 -0700 Burton Radons
<loth@users.sourceforge.net>
> wrote:
>
>
>> Pavel, you didn't +1 anything here.  Do you have any syntax in
>> mind, or are they all equally evil?
>>
>
> Citing myself: =)
>
>
>>> 16) a !<> b, a <> b, a !> b, a !< b, a !<= b, a !>= b.  (my
>>> vote: 0) IMO this is an eq/cmp combination issue.
>>>
>> The same argument as >=, >, <, <= above.  This is simply
>> implemented as a combination of eq and cmp, which expresses
>> everything we need to do these properly.  Explicitly allowing
>> them is confusing.
>>
>
> This is NOT just a simple combination of eq() and cmp() - how would you
>  express D floating-point comparisons (RTFM!) this way?


Through a simple combination of eq and cmp (with bugs, indubitably):

== is eq
!= is !eq
> is cmp > 0
>= is cmp >= 0 or eq
< is cmp < 0
<= is cmp <= 0 or eq
!<>= is !cmp and !eq
<> is cmp
<>= is cmp or eq
!<= is cmp <= 0 or !eq
!< is cmp < 0 or !eq
!>= is cmp >= 0 or !eq
!> is cmp > 0 or !eq
!<> is cmp or !eq

For the operations which can throw exceptions, we could leave them alone
if only cmp or eq are overloaded, and throw if they're incompatible -
for example, with <=, if cmp returns zero but eq returns false, it's
unordered, hence one is NaN and an exception can be thrown.

Walter, could you back one of us up here, please?

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D5F0476.1060203@users.sourceforge.net...
> Walter, could you back one of us up here, please?

I think it will work right if:
    a op b
is rewritten as:
    a.cmp(b) op 0
For the nan cases, the cmp function can return nan's.

On Sun, 18 Aug 2002 16:47:56 -0700 "Walter" <walter@digitalmars.com> wrote:

> I think it will work right if:
>     a op b
> is rewritten as:
>     a.cmp(b) op 0
> For the nan cases, the cmp function can return nan's.

Then cmp() needs to be defined as "float cmp(a, b)".

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374873976712963@news.digitalmars.com...
> On Sun, 18 Aug 2002 16:47:56 -0700 "Walter" <walter@digitalmars.com>
wrote:
>
> > I think it will work right if:
> >     a op b
> > is rewritten as:
> >     a.cmp(b) op 0
> > For the nan cases, the cmp function can return nan's.
>
> Then cmp() needs to be defined as "float cmp(a, b)".

Yes - you can define it to return anything you want <g>.

On Mon, 19 Aug 2002 17:52:08 -0700 "Walter" <walter@digitalmars.com> wrote:

>> Then cmp() needs to be defined as "float cmp(a, b)".
> 
> Yes - you can define it to return anything you want <g>.

Doesn't Object define it as int cmp() already?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374884975017593@news.digitalmars.com...
> Doesn't Object define it as int cmp() already?

Correct. But if you overload it, you can change the return type - but be aware that will create more than one entry for cmp in the vtbl[].

>Correct. But if you overload it, you can change the return type - but be aware that will create more than one entry for cmp in the vtbl[].
Um, I think overload is too strong a word for this.  "Fudge" might be more accurate <g>.  It might be good if you could overload based on just the return type--but you can't in the current implementation.

For example, this bogus code won't compile:
class A {
int neg() { return -1; }
char[] neg() { return "-1"; }
void neg() { assert(false); }
}

void foo()
{
A a;
-a;
int i = -a;
char[] s = -a;
}

Though, FWIW, it should be noted that if you fudge the return type of neg to void and don't provide the other overloads, you can keep the operator from being used to create an rvalue.