http://d.puremagic.com/issues/show_bug.cgi?id=1596
--- Comment #8 from Don <clugd...@yahoo.com.au> 2011-07-05 13:22:33 PDT ---
(In reply to comment #7)
> (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.
The rules you made up about lowering not involving signatures. Almost every
case where the compiler recognizes particular names, it requires a particular
signature. The existing opAddAssign is one of the few cases where the
requirements are loose.
> 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.
Basically, the more you can enforce semantics of operators, the more useful
they are. In C++, the STL is based entirely on agreed semantics of operators.
>
> > > 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) {...}
> }
That doesn't work with const(T).
> > > 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.
(4) is untrue. (3) was discussed by Andrei. Although it sounds plausible, and
it's the reason it existed in C++, experience in C++ has shown that this is NOT
true. It has been thoroughly explored, and it is not a useful feature. So (3)
isn't true either.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
