I asked this question before but here it is again:
For example i have this code

class A
{
 A opShl(int x)
 {
  printf("%d",x);
  return this;
 }
 A opShl(char[] x)
 {
  printf("%.*s",x);
  return this;
 }
}

class B
{
 A opShl_r(A a)
 {
  //some code..
  return a;
 }
}

int main(char[][] args)
{
 A a;
 a << 4 << " " << 12 << "\n";
 B b = new B();

 a << b;
 getch();
 return 1;
}

The line a<<b; causes this compilation error:
E:\D language\learn_d\cout\cout.d(36): function opShl (int x) does not match
argument types (B )

The compiler look for A.opShl(B) but it doesnt seam to look for
B.opShl_r(A)??
If A.opShl(*) functions don't exist then the compiler finds and calls
B.opShl_e(A),
but then the first line
 a << 4 << " " << 12 << "\n";
doesn't work!

So is this a bug?
I hope it is and that it gets fixed!

Ivan Senji wrote:

[...]
> The compiler look for A.opShl(B) but it doesnt seam to look for
> B.opShl_r(A)??
[...]

From the spec:
|       a op b
[...]
| If a is a struct or class object reference that contains a member named
| opfunc, the expression is rewritten as:
|	a.opfunc(b)

Because your A contains `opShl' this rule holds and your B is not searched for `opShl_r'.

According to the current specification it is not a bug to consider your code as erroneous.

However, I consider the specification as either buggy itself, because it only defines a precendece, wheras it should disallow operands competing for operators at all, or the specification should be extended, so that only operands competing for operators using corresponding signature pairs are disallowed.

Thoughts?

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:c3rdt2$1d7g$1@digitaldaemon.com...
> Ivan Senji wrote:
>
> [...]
> > The compiler look for A.opShl(B) but it doesnt seam to look for
> > B.opShl_r(A)??
> [...]
>
> From the spec:
> |       a op b
> [...]
> | If a is a struct or class object reference that contains a member named
> | opfunc, the expression is rewritten as:
> | a.opfunc(b)
>
> Because your A contains `opShl' this rule holds and your B is not searched for `opShl_r'.

I dont't agree! A contains functions opShl(int) and opShl(char[]) but it
doesnt contain
opShl(B) so it should still check if B contains opShl(A).

> According to the current specification it is not a bug to consider your code as erroneous.
>
> However, I consider the specification as either buggy itself, because it only defines a precendece, wheras it should disallow operands competing for operators at all, or the specification should be extended, so that only operands competing for operators using corresponding signature pairs are disallowed.
>
> Thoughts?
>
>

Manfred Nowak schrieb:
> However, I consider the specification as either buggy itself, because it
> only defines a precendece, wheras it should disallow operands competing
> for operators at all, or the specification should be extended, so that
> only operands competing for operators using corresponding signature pairs
> are disallowed.

So it is. The purpose of _r overloads was to be able to add new overloads in newly written classes to the already exisiting infrastructure. With a current limitation, it does not fulfill this purpose.

Consider that, e.g. class A is in the library, and B is user-written. A defines some operators for built-in and library types. Now this operator also should be made work with user types. The only sensible way to accomplish this is that if an overload search in A failed (that is, there possibly is an operator overload, but it doesn't match) a reversed overload has to be searched in B.

Walter: was it a conscious decision to disallow that _r overloads be ignored in B if A defines some direct overload of this operator? The way it is now it's utterly useless and you could just as well remove all _r overloads!

-eye

Ivan Senji schrieb:

> I dont't agree! A contains functions opShl(int) and opShl(char[]) but it
> doesnt contain
> opShl(B) so it should still check if B contains opShl(A).

I don't "agree" either, but so is the current spec. I checked it.

-eye

Huh?! But A<<B is not the same as B<<A. I think you are trying to abuse the operator, and Walter doesn't like that. The << operator should _only_ be used to perform a left-shifting operation, which is not commutative.


In article <c3sbqj$2s6n$2@digitaldaemon.com>, Ilya Minkov says...
>
>Ivan Senji schrieb:
>
>> I dont't agree! A contains functions opShl(int) and opShl(char[]) but it
>> doesnt contain
>> opShl(B) so it should still check if B contains opShl(A).
>
>I don't "agree" either, but so is the current spec. I checked it.
>
>-eye

"Juan c" <Juan_member@pathlink.com> wrote in message news:c3sf1l$ib$1@digitaldaemon.com...
> Huh?! But A<<B is not the same as B<<A. I think you are trying to abuse
the
> operator, and Walter doesn't like that. The << operator should _only_ be
used to
> perform a left-shifting operation, which is not commutative.
>

A.opShl(B) should be same as B.opShl_r(A).
I don't think it is abusing the operator if I am trying to use it to write
simpler code! I (and probably a lot of other people coming from C++) see <<
and >> as stream operators before left-shifting.
Someone may overload a static opCall operator to be able to use it like this
A a = A(3,5);
instead of
A a = new A(3,5);
Is this also abuse? I see it as a freedom to express your ideas in different
ways.

>
> In article <c3sbqj$2s6n$2@digitaldaemon.com>, Ilya Minkov says...
> >
> >Ivan Senji schrieb:
> >
> >> I dont't agree! A contains functions opShl(int) and opShl(char[]) but
it
> >> doesnt contain
> >> opShl(B) so it should still check if B contains opShl(A).
> >
> >I don't "agree" either, but so is the current spec. I checked it.
> >
> >-eye
>
>

In article <c3sf1l$ib$1@digitaldaemon.com>, Juan c says...
>
>Huh?! But A<<B is not the same as B<<A. I think you are trying to abuse the operator, and Walter doesn't like that. The << operator should _only_ be used to perform a left-shifting operation, which is not commutative.
>
>

But he isn't doing that. He defined A.opShl(int) so he can do A<<3. He also wants to do A<<B, so he defined B.opShl_r(A), which should work, but doesn't. Yes, maybe he is abusing the operator, but that's his problem. Or maybe not: what if B is BigInteger? Then he wouldn't be abusing. One way or another, he's in all his rights to do things like this.

-------------------
Carlos Santander B.

Ilya Minkov wrote:

[...]
> The purpose of _r overloads was to be able to add new overloads in newly written classes to the already exisiting infrastructure.
[...]

Do you have a reference for this? I ask, because I do not believe, that classes in any infrastructure are not allowed to have other types than classes/structs on the left side of a non commutative operator.

[...]
> but it doesn't match) a reversed overload has to be searched in B.

I do not believe that it is possible to code such overloads in the general case you established as an example. How can you assure, that it would suffice to have access to the public parts of class/struct A?


[...]
> you could just as well remove all _r overloads!

A stated above `B.opfunc_r(int)' may still make sense.

So long!

Ivan Senji wrote:

[...]
> A.opShl(B) should be same as B.opShl_r(A).
[...]

Should be. But this cannot be checked in the general case. Therefore the coexistence of both must be forbidden.

I am unsure whether the compiler should check that for all possible competing classes/structs or it may suffice to check it only, when such classes/structs actually compete.

[...]
> see << and >> as stream operators
[...]

Which is a strange and counter intuitive speciality made for {101}'s, not suitable for {500}'s.

So long!