www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - What is the state of opAssign?

reply BCS <BCS pathlink.com> writes:
Is it or will it be possible, in v1.0 or v2.0, to define overloads sutch 
that this works?

class C{}

auto c = new C;

real r = c;
Oct 19 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"BCS" <BCS pathlink.com> wrote in message 
news:ffbf1l$cbo$1 digitalmars.com...

 Is it or will it be possible, in v1.0 or v2.0, to define overloads sutch 
 that this works?

 class C{}

 auto c = new C;

 real r = c;



It's called opImplicitCast, and yes, it will be in D2.
Oct 19 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Jarrett,


 "BCS" <BCS pathlink.com> wrote in message
 news:ffbf1l$cbo$1 digitalmars.com...
 

 Is it or will it be possible, in v1.0 or v2.0, to define overloads
 sutch that this works?
 
 class C{}
 
 auto c = new C;
 
 real r = c;
 



 



Hmmm. I was hoping for something along the lines of opAssing_r because I'm 
hoping to use the original value of the lvalue for something.

would this work

class C
{
    static C opImplicitCastFrom(real r){...}
    C opAssign(B b){...}
}

class B {}

auto b = new B;
real r = 5;
r = b;  //opImplicitCastFrom(r).opAssign(b);
Oct 19 2007
parent reply Nathan Reed <nathaniel.reed gmail.com> writes:
BCS wrote:

 would this work
 
 class C
 {
    static C opImplicitCastFrom(real r){...}
    C opAssign(B b){...}
 }
 
 class B {}
 
 auto b = new B;
 real r = 5;
 r = b;  //opImplicitCastFrom(r).opAssign(b);
 
 



I'd be very suspicious of using the return value of a function as an lvalue!

What is the value in 'r' after this code has executed??

Thanks,
Nathan Reed
Oct 20 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Nathan,


 BCS wrote:
 

 would this work
 
 class C
 {
 static C opImplicitCastFrom(real r){...}
 C opAssign(B b){...}
 }
 class B {}
 
 auto b = new B;
 real r = 5;
 r = b;  //opImplicitCastFrom(r).opAssign(b);



 lvalue!
 
 What is the value in 'r' after this code has executed??
 
 Thanks,
 Nathan Reed



Depends on what I'm doing with it. In the simple case, the above would work 
as expected but would be able to also do something with r.

struct C
{
  real* rr;
  static C opImplicitCastFrom(ref real r)
  {
    C ret;
    ret.rr = & r;
    return ret;
  }
  C opAssign(B b)
  {
    //... uses rr
    //*rr = cast(real) b;
  }
}
class B {}
Oct 20 2007
parent reply Nathan Reed <nathaniel.reed gmail.com> writes:
BCS wrote:

 Reply to Nathan,
 

 BCS wrote:


 would this work

 class C
 {
 static C opImplicitCastFrom(real r){...}
 C opAssign(B b){...}
 }
 class B {}

 auto b = new B;
 real r = 5;
 r = b;  //opImplicitCastFrom(r).opAssign(b);



 lvalue!

 What is the value in 'r' after this code has executed??

 Thanks,
 Nathan Reed



 Depends on what I'm doing with it. In the simple case, the above would 
 work as expected but would be able to also do something with r.
 
 struct C
 {
  real* rr;
  static C opImplicitCastFrom(ref real r)
  {
    C ret;
    ret.rr = & r;
    return ret;
  }
  C opAssign(B b)
  {
    //... uses rr
    //*rr = cast(real) b;
  }
 }
 class B {}
 
 



Frankly, I think this is a very bad idea.  With the usual semantics of 
assignment are it *doesn't* depend on the current value of the lhs. 
Overloading an operator such that its semantics violates the assumptions 
programmers normally make about it is never good imho.  This is why D 
doesn't allow commutative operators to be overloaded as non-commutative, 
etc...

Thanks,
Nathan Reed
Oct 20 2007
parent BCS <ao pathlink.com> writes:
Reply to Nathan,



 Frankly, I think this is a very bad idea.  With the usual semantics of
 assignment are it *doesn't* depend on the current value of the lhs.
 Overloading an operator such that its semantics violates the
 assumptions programmers normally make about it is never good imho.
 This is why D doesn't allow commutative operators to be overloaded as
 non-commutative, etc...
 
 Thanks,
 Nathan Reed



Point taken. However In the case I'm using, the semantics would be as expected 
because I'd be modeling a different semantic system. OTOH, I think I might 
be able to avoid that issue by defining the assignment from the left side 
(I might be forced to anyway by other constrains).
Oct 21 2007