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;

"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.

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;
>> 
> It's called opImplicitCast, and yes, it will be in D2.
> 

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);

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

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);
> 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

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 {}

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);
>> 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
> 
> 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

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).