Pavel Minayev wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C690E8D.37852B1@deming-os.org...
>
> > > The question is, should logical operators be overloaded?
>
> I meant && and ||.

Oh :)

> Yes, like in C#. The same should, IMO, apply to ++, -- and op= - you can supply them if you want, but if you don't, they are generated automatically from +, - and op.

True.  Many of the common operators can be generated from each other.  I think that you should be able to supply just a few of them and have the complier automatically provide implementations for the rest.  For instance, a-b can be redone as a+(-b), which in most cases is not the optimal solution performance-wise, but it allows rapid development of simple classes.

You should be able to do it in many different ways, as well.  Sometimes it's easiest to provide = and +, other times it's easiest (and often more efficient) to provide = and +=.  The compiler should provide the missing operators if it can.

Walter, I know that this means some extra complexity for you, but I would guess that it wouldn't be *too* bad.  Each operator can have a library of available automatic implementations...depending on which operators are provided by the programmer, the compiler drops in pretty standard code for each.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C690E8D.37852B1@deming-os.org...
> I would like to see the compiler provide the remaining logical operators
if only
> a few are defined.  That is, if you define
>
> operator==(Foo,int);
>     and
> operator<(Foo,int);
>
> (or any other combination of equality and inequality operators) the
compiler
> should be able to provide the rest.  Of course, it won't always be 100% optimized...but if it's not, you can provide the rest of the operators yourself.  I just always hated having to have 4 extra useless functions
just to
> define !=  <=  >= and > for every class.

If just a cmp() was provided, that can be used for all the comparisons.

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C690DAF.995AB2CB@deming-os.org...
> > 1) The idea of 'special' operators for overloading, like :+: being the overloadable version of +, is a good idea, but it fails when used with templates.
> Are you suggesting that a special operator (like :+:) would always be
associated
> with the related operator function operator+   ?   While I personally like having the same operators, I think this might be an excellent balance...it
makes
> it clear that the operator is not a compiler operator, but it allows an
inline
> syntax.

The trouble is you couldn't write a template that could be instantiated for both builtin types and user defined types.

> We still have to deal with the issues of things like dot-product vs. cross-product in vectors.  What if we used the same syntax for inline
function
> names?  Basically, if you defined a function name with 2 arguments, you
could
> call it as func(arg1,arg2)   or    arg1 :func: arg2.  Similarly, for those
for
> whom a trailing unary operator is useful (like factorial), you could call
a
> single-function argument with similary syntax     arg :unary-func:    Each
of
> these syntaxes would be EXACTLY equivalent to the old C function call
syntax,
> func(arg1,arg2)    and   unary-func(arg),  respectively.
>
> class Vector {
>     static Vector cp(Vector a,Vector b);
>     static double dp(Vector a,Vector b);
> }
>
> long fact(int i);
>
> Vector foo,bar;
> ...
> double d = a :dp: b;
> Vector baz = a :cp: b;
> long fred = 6 :fact: ;
>
> It's not pretty, but it allows an inline syntax of a sort without allowing
wild
> creation of unlimited functions.

Perhaps this could be in a future version of D, but let's defer that for now.

> > 2) Overloaded operator functions should be inlineable, which lets out interfaces.
>
> I'm uncomfortable about this (losing interfaces) in general, but I'm not
totally
> sure why.  I would desire some more details about why interfaces get in
the way.

I just don't see any advantage to using interfaces for this, and an interface requires a vptr.

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C694E30.7FE96594@deming-os.org...

> True.  Many of the common operators can be generated from each other.  I
think
> that you should be able to supply just a few of them and have the complier automatically provide implementations for the rest.  For instance, a-b can
be
> redone as a+(-b), which in most cases is not the optimal solution performance-wise, but it allows rapid development of simple classes.

This might not be a good idea - not so obvious to many people =) It is clear that + can be used to implement += and ++. But a+(-b) just doesn't fit sometimes...

"Walter" <walter@digitalmars.com> wrote in message news:a4aril$ue9$2@digitaldaemon.com...
>
> I've been thinking a lot about operator overloading.
>
> 1) The idea of 'special' operators for overloading, like :+: being the overloadable version of +, is a good idea, but it fails when used with templates.

Right.  One of the beauties of templates is being able to write T a = b + c; when you don't even know what class b and c are, so long as it provides operator = and operator +, it'll compile.

> 2) Overloaded operator functions should be inlineable, which lets out interfaces.

Right.  When you need operator overloading you usually can't afford a virtual function call.

> 3) I just don't like the idea of operator functions having hidden
arguments:
>
>     int operator+(int y);
>
> A binary operator function should, gosh darn it, have TWO operands:
>
>     static int operator+(Foo x, int y);

I agree.  It should be explicit.  I also can't see why you shouldn't be able to override operators using only basic types.  So what if I want to implement <<= for floats?  Let me.

> 4) I don't see a point to smart pointers and such in a garbage collected language. Overloadable operators should be restricted to arithmetic operators.

With smart pointers it's not just about refcounting... You can also restrict the pointer from being incremented or changed (prevents bugs when returning a pointer to just one thing, such as a global singleton).  You can use them as accessors (if you want to talk to object X, you have to get a lock first... so obtaining one of these XAccessor objects which are smart pointers into X, automatically locks the X, and is the only way for outside code to use X, since all its methods are private to everything but the XAccessor, which forwards calls to it).

> 5) Operator overloading should only be used to provide arithmetic
operations
> on user defined arithmetic types. None of that << and >> for iostreams. I know many people like that, but a shift is not a stream operation. It just isn't.

I could live with that.

> 6) I see no way to have the compiler enforce (5). Anyone caught violating
> (5) should be forced to carry the Stone of Shame.
>
> 7) Note (3) means no virtual operator functions. To do that, you'd need:
>     static int operator+(Foo x, int y)
>     {
>         return x.myadd(y);
>     }
> so no great loss.
>
> 8) If there are to be conversion operators, they will not participate in implicit conversions, only explicit ones.

Also tolerable.

> None of this is implemented or specified yet, it's just some thoughts.

Glad to see you're thinking about it.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:a4bm6j$1a5o$2@digitaldaemon.com...

> If just a cmp() was provided, that can be used for all the comparisons.


Hmmm... operator cmp?

    enum Relation { Less, Equal, Greater }    // builtin

    Relation operator cmp(vector a, vector b)
    {
        ...
    }

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C690E8D.37852B1@deming-os.org...
> Pavel Minayev wrote:
>
> > > 4) I don't see a point to smart pointers and such in a garbage
collected
> > > language. Overloadable operators should be restricted to arithmetic operators.
> >
> > I suppose you mean binary + - * / & | ^ ~ and unary ++ -- ~ ! and all the op= operators?
> >
> > The question is, should logical operators be overloaded?
>
> I would like to see the compiler provide the remaining logical operators
if only
> a few are defined.  That is, if you define
>
> operator==(Foo,int);
>     and
> operator<(Foo,int);
>
> (or any other combination of equality and inequality operators) the
compiler
> should be able to provide the rest.  Of course, it won't always be 100% optimized...but if it's not, you can provide the rest of the operators yourself.  I just always hated having to have 4 extra useless functions
just to
> define !=  <=  >= and > for every class.

YES!!! GOD, YES!!

Sean

Walter wrote:

> If just a cmp() was provided, that can be used for all the comparisons.

True, but that is only for things that are reasonably ordered.  Some things may have a property of equality/inequality but not ordering.  In that case, you want to supply == and != but not < > <= >=

Think (literally) apples and oranges :)

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Walter wrote:

> The trouble is you couldn't write a template that could be instantiated for both builtin types and user defined types.

You could simply define that for built-in types :+: is exactly equivalent to +    Or am I missing the point here?

> Perhaps this could be in a future version of D, but let's defer that for now.

ok.  It's nice to think that the language isn't static, and that we have the time to slowly learn what the truly useful features are! :)

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a4bq9a$1buc$1@digitaldaemon.com...

> With smart pointers it's not just about refcounting... You can also
restrict
> the pointer from being incremented or changed (prevents bugs when
returning
> a pointer to just one thing, such as a global singleton).  You can use
them
> as accessors (if you want to talk to object X, you have to get a lock first... so obtaining one of these XAccessor objects which are smart pointers into X, automatically locks the X, and is the only way for
outside
> code to use X, since all its methods are private to everything but the XAccessor, which forwards calls to it).

Oh yes, and there are also iterators - kinda pointers as well =)

> > None of this is implemented or specified yet, it's just some thoughts.
>
> Glad to see you're thinking about it.

With operator overloading and templates, D would easily beat both C++ and C#, for sure. =)