> What's really important is that operators be not always bound to
instances,

Could you tell me what you mean here, with an example ?

> I'm not sure it's necessary to vote on this, because I think this will be change that will be forced on D

Yea but I personally would like this ASAP, i dont like the current inconsistent convention and am hoping each release will fix it.

C


"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bp3dfi$2qs9$1@digitaldaemon.com...
> I don't care too much about what they're called (although I don't like the current naming conventions much).
>
> What's really important is that operators be not always bound to
instances,
> i.e. we can (and should) declare binary operators as free functions, and
we
> should have the right to do so with unary operators.
>
> I'm not sure it's necessary to vote on this, because I think this will be change that will be forced on D (i.e. on Walter) at some point, as the problems associated with the current approach become too great to ignore.
>
> IMO, if that change does not happen, D will founder
>
> "Carlos Santander B." <carlos8294@msn.com> wrote in message news:bp1fs0$2oat$1@digitaldaemon.com...
> > Should we vote this again? I mean, there're some complaining about how overloaded operators should work...
> >
> > "Burton Radons" <loth@users.sourceforge.net> wrote in message
> > news:3D5278B0.1000508@users.sourceforge.net...
> > | I've accidentally implemented operator overloading in my port.  It was
> > | kind of incidental to other work, so I thought "what the hell" and
threw
> > | it in.  But this brings up the whole issue of syntax, and I think that
> > | should be voted on to specify the syntax on my side and to influence
> > | Walter when he decides to do this topic.
> > |
> > | I'd like Apache-style voting to be used, where the voting is
either -1,
> > | -0, 0, +0, or +1 for any option, which is a good bellweather of how
> > | people think about something.
> > |
> > | First off, the naming scheme:
> > |
> > | 1) "add", "mul", "div", etc.  (my vote: +1)
> > |
> > |      Vector mul (Vector b);
> > |      Vector div (Vector b);
> > |
> > | 2) "op_add", "op_mul", "op_div", etc.  (my vote: +1)
> > |
> > |      Vector op_sub (Vector b);
> > |      Vector op_mod (Vector b);
> > |
> > | 3) "operator +".  (my vote: -1)  My vote is because I find this syntax
> > | confusing in C++, particularly with its wide expressiveness, and I
> > | admire any syntax which doesn't require a change to tools, as the
above
> > | don't.
> > |
> > |      Vector operator + (Vector b);
> > |
> > | 4) 'operator "+"'.  (my vote: -0)  For some reason I find this less
> > | visually disconcerting.
> > |
> > |      Vector operator "*" (Vector b);
> > |
> > | 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);
> > |
> > | Now, where overloaded operators are defined:
> > |
> > | 1) Operators are normal, possibly virtual methods in classes, normal
> > | nonvirtual methods in structs (My vote: +1).
> > |
> > |      Vector add (Vector b);
> > |
> > | 2) Overloaded operators are always static methods with both left and
> > | right arguments defined (My vote: 0).
> > |
> > |      static Vector add (Vector a, Vector b);
> > |
> > | 3) Overloaded operators are global functions, using both arguments (My
> > | vote: -1).
> > |
> > |      Vector add (Vector a, Vector b);
> > |
> > | 4) Operator overloading shouldn't be put in (My vote: -1).
> > |
> > | Now, reverse operator handling, where you want the right-side
expression
> > | to handle the evaluation, such as with the form "int * Vector":
> > |
> > | 1) A second set of potential functions (My vote: +1).
> > |
> > | 2) Automatic reorganization of the expression.  This makes assumptions
> > | about what the operators do and can't handle "1 / Vector" (My
vote: -1).
> > |   For example, "1-A" could become "-A+1".
> > |
> > | Now for the operations covered.  Please be temperate with your votes -
> > | operations can be added later, but they can't be removed as easily.
> > |
> > | 1) a + b, a - b, a * b, a / b, a % b, -a, +a.  (my vote: +1)
> > |
> > | 2) a & b, a | b, a ^ b, ~a, !a.  (my vote: +1)
> > |
> > | 3) a++, a--, --a, ++a.  (my vote: 0)
> > |
> > | 4) a = b.  (my vote: 0)
> > |
> > | 5) a << b, a >> b, a >>> b.  (my vote: +1)
> > |
> > | 6) a += b, a -= b, a *= b, a %= b, etc.  (my vote: -1)
> > |
> > | 7) new, delete.  (my vote: -0)
> > |
> > | 8) a || b, a && b.  (my vote: -1)
> > |
> > | 9) explicit a >= b, a > b, a <= b, a < b.  (my vote: -1)
> > |
> > | 10) a [b].  (my vote: +1)
> > |
> > | 10a) a [b] = c.  (my vote: +0)
> > |
> > | 11) a [b .. c].  (my vote: +1)
> > |
> > | 12) &a, *a.  (my vote: -1)
> > |
> > | 13) a.b, a.b = c.  Retrieve and assign property.  (my vote: +1)  Note
> > | that this won't allow just anything in b.
> > |
> > | 13a) a . b, where b can be any type.  (my vote: -1)
> > |
> > | 14) a ? b : c.  (my vote: -1)
> > |
> > | 15) a === b, a !== b.  (my vote: 0)
> > |
> > | 16) a !<> b, a <> b, a !> b, a !< b, a !<= b, a !>= b.  (my vote: 0)
> > | IMO this is an eq/cmp combination issue.
> > |
> > | 17) a in b.  (my vote: +1)
> > |
> > | 18) cast (b) a.  (my vote: -0)  I haven't had any good experiences
with
> > | cast overloading in C++.
> > |
> > | 19) (a, b).  (my vote: -1)
> > |
> > | And miscellaneous:
> > |
> > | 1) Operator overloading should be allowed on basic types as global
> > | functions.  (my vote: -1)
> > |
> > |      int operator "a - b" (int a, int b);
> > |
> > | 2) Definition of new operators is allowed.  I'll ignore this one if it
> > | goes positive.  (my vote: -1)
> > |
> > |      Vector operator (this dot b) (Vector b);
> > |
> > | 2a) Setting precedence of new operators is allowed.  I'll ignore this
> > | one if it goes positive.  (my vote: -1)
> > |
> > |      operator (a dot b) above (a >= b) below (a * b);
> > |
> > | I think that's about it.
> > |
> >
> >
> > ---
> >
> > Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.538 / Virus Database: 333 - Release Date: 2003-11-10
> >
> >
>
>

"Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bp40ik$plv$1@digitaldaemon.com...
>
> > What's really important is that operators be not always bound to
> instances,
>
> Could you tell me what you mean here, with an example ?

1. Operators as instances (C++ syntax, I'm afraid):

class X
{
  X operator +(X const &rhs); // "this" is the lhs
};

2. Free functions:

class X
{}

X operator +(X const &lhs, X const &rhs);


> > I'm not sure it's necessary to vote on this, because I think this will
be
> > change that will be forced on D
>
> Yea but I personally would like this ASAP, i dont like the current inconsistent convention and am hoping each release will fix it.

Me too, but there seems much resistance on Walter's part. I can see that it's probably a big job.

It will happen eventually, though, I have no doubt

"davepermen" <davepermen_member@pathlink.com> wrote in message news:bp2hml$1dlq$1@digitaldaemon.com...
> 3) specify by some token.. like
> Vector operator+ (Vector a,Vector b) reversible {
> return add(a,b);
> }
> (reversible isn't the mathematical term.. but i'm too tierd currently to
use my
> brain for remembering that term..)

It's called commutativity


> 1) a + b, a - b, a * b, a / b, a % b, -a, +a.
> +1
> 2) a & b, a | b, a ^ b, ~a, !a.
> !a doesn't fit in this list as the rest are binary ops.. for binary ops:
> +1
> for !
> 0

You're mistaken.  Look again.

> 3) a++, a--, --a, ++a.
> for --a and ++a, yes. a++,a-- should be autoimplemented.. its just a
changing of
> the order.. but they can be useful for iterator thingies..
> +0
> 4) a = b.  (my vote: 0)
> +0
> i think yes.
> but as a binary operator, not the way c++ does with possibility of a
> constructor, or an operator AType()
> void operator = (TypeA a,TypeB b) {
> a.set(b);
> }

You are right, construction and destruction do not make sense most of the time, it is conversion or production that gives us 99% of our values.  Let's focus on that.  Assignment is pretty fundamental to procedural languages. Assigning one value to a variable of another type is an implicit conversion, and those are really good to be able to define simply, OUTSIDE of the class declaration, because otherwise you get into the C++ mess of user-defined conversions which are exactly the same thing as constructors, if you really think about it.  The copy constructor could likewise be eliminated, and becomes a special case of assigning a value to an lvalue of its own type, in other words same as the basic assignment operator.

> 5) a << b, a >> b, a >>> b.  (my vote: +1)
> +1
> 6) a += b, a -= b, a *= b, a %= b, etc.
> if we have them, we don't need 1) actually..
> +0
> 7) new, delete.
> +1
> if the way they are done now.. they can be useful.

I've never really liked new and delete.  I would love to get rid of them and just use factory / demolition functions (assignments to/from void work for this purpose).

> 10) a[b].
> +1
> 10a) a[b] = c.
> uhm?

array store (array used as lvalue)

> 12) &a, *a.
> -1

The C++ purpose for these being overloadable is to provide and dereference
pointer types.  &a is pretty much the equivalent of saying a.begin(), null
is almost equivalent to a.end().
If you use them, you give up the ability to take the address of a variable,
you "wrap" that type's pointer capability.

> 1) Operator overloading should be allowed on basic types as global
functions.
> -1

Why not?

++float
float >> 1

These are good examples of why I think it *should* be allowed.  The language designers "forgot" those operations, creating little pitfalls and minefields in template authoring.

> 2) Definition of new operators is allowed.  I'll ignore this one if it
goes
> positive.
> -1

I hate you all!!  There are not nearly enough operators to go around.

Sean

quoting {
> 2) a & b, a | b, a ^ b, ~a, !a.
> !a doesn't fit in this list as the rest are binary ops.. for binary ops:
> +1
> for !
> 0

You're mistaken.  Look again.
}

first: i made a typo. but my statement is correct. !a is no binary op. its an unary op:D (read up yourself).

what i ment is, ! is not a bitwise op. the others are. a&b ands all bits. a|b ors all bits, a^b xors all bits, ~a inverts all bits, but !a returns a boolean, and only checks if all bits are zero, or not, to return that boolean.

! belongs to &&,||, a possible ^^ (hehe:D), etc.. it is a logical op. not a bitwise op. i just checked the docu's, and it still is. as in c++.

Doh!  I thought you meant binary as in "not unary", instead of what you really meant, which was "not logical".  ;)

Sean


"davepermen" <davepermen_member@pathlink.com> wrote in message news:bpnsck$2r4l$1@digitaldaemon.com...
> quoting {
> > 2) a & b, a | b, a ^ b, ~a, !a.
> > !a doesn't fit in this list as the rest are binary ops.. for binary ops:
> > +1
> > for !
> > 0
>
> You're mistaken.  Look again.
> }
>
> first: i made a typo. but my statement is correct. !a is no binary op. its
an
> unary op:D (read up yourself).
>
> what i ment is, ! is not a bitwise op. the others are. a&b ands all bits.
a|b
> ors all bits, a^b xors all bits, ~a inverts all bits, but !a returns a
boolean,
> and only checks if all bits are zero, or not, to return that boolean.
>
> ! belongs to &&,||, a possible ^^ (hehe:D), etc.. it is a logical op. not
a
> bitwise op. i just checked the docu's, and it still is. as in c++.

hehe sorry..
:D

In article <bpsljg$hlc$1@digitaldaemon.com>, Sean L. Palmer says...
>
>Doh!  I thought you meant binary as in "not unary", instead of what you really meant, which was "not logical".  ;)
>
>Sean