[Issue 1596] op*Assign should return void

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=1596



--- Comment #7 from Steven Schveighoffer <schveiguy at yahoo.com> 2011-07-05 09:02:07 PDT ---
(In reply to comment #6)
> (In reply to comment #5)
> > D should not be forcing behavior on normal functions, which operators are. 
> > They are special in that if defined in a specific way, they will be used when
> > using operators, but other than that, they are ordinary functions.  If you want
> > to force behavior, make the operators keywords (like C++).  Otherwise, you have
> > special rules for ordinary symbols.  Lowering is supposed to work by simply
> > rewriting code, not by requiring certain signatures.
> 
> ??? 
> The existing language doesn't obey these rules, which you've apparently just
> made up.

What rules?  There should be no "rules" of what an ordinary function should be
or should not return.  I believe the current compiler works this way, at least
in terms of opAddAssign.

When the compiler sees a += b, it should rewrite as a.opAddAssign(b) (or
whatever the equivalent template should be).  Why does it matter what
opAddAssign returns?  If it returns a C, who cares?  There is nothing special
about opAddAssign except that it's the vehicle to implement += via lowering.

> > This relates to Andrei's later bug regarding opEquals - the compiler currently
> > requires a certain signature for opEquals, and it simply gets in the way of
> > writing efficient or usable code.
> 
> Actually the problem with opEquals is that there is NO option which works
> properly. Giving you more bad options wouldn't help.

Of course there is:

struct T
{
  bool opEquals(T other) {...}
}

The issue with opEquals (and this is different from opAddAssign) is the
compiler will use opEquals to populate the xequals function pointer in the
TypeInfo, if it is the right signature.

The error in the current compiler is that opEquals does not even compile unless
you use a useless signature.  This "feature" was added to fix something else,
but I think it was an error to add it.

I should be able to do:

bool opEquals(int other)

if I so wish, and it just won't populate the xequals function.  It's a normal
symbol, and should be a normal function.  opEquals is not a special token, it's
a normal symbol.

> > Besides, I think Andrei's original point is that it was impossible to do the
> > most efficient thing (return the lvalue of this), which is no longer the case.
> > So this was an attempt to solve that problem using a language rule instead of
> > adding ref returns.
> 
> No. The point is this: There is only ONE correct choice for the return value:
> it must be some form of 'return this'. The compiler is better equipped to work
> out the most efficient way to do it, than the programmer is.

opAddAssign probably should return this.  But it could also return void.  Or it
could return int.  It shouldn't matter to the compiler.

> Giving freedom to choose the return value does only two things: 
> (1) it gives you an opportunity to make a mistake. 
> (2) it adds extra noise in the code.

(3) it allows some future use we do not foresee, people can be inventive.
(4) it makes the compiler simpler and more consistent.

BTW, what is the extra noise in the code?  The specification of the return
value?  I find this a weak argument.  What if you want to return by ref or by
value?  Don't get me wrong, I think in most cases, it should return this by
reference.  But there could be cases where returning something else would be
advantageous.  For example, what if you have a struct parameterized on
constancy, and you want to return a different const form?  There are some crazy
amazing things I've seen in phobos and other code that nobody thought of
before, and some of it is based on unintuitive uses of operators.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------