• Denis Koroskin (14/14) Oct 22 2009 For some reason compiler rewrites someComplexVar.re and someComplexVar.i...
• Lars T. Kyllingstad (5/23) Oct 23 2009 I don't know whether the current behaviour is intentional, but in

"Denis Koroskin" <2korden gmail.com> writes:

For some reason compiler rewrites someComplexVar.re and someComplexVar.im  
into cast(real)someComplexVar and cast(ireal)someComplexVar respectively,  
which results in those variables being non-lvalues and me being unable to  
update either of a properties independently of each other. As one of the  
consequences, I can't set imaginary part of a complex variable to  
signalling nan:

real snan = real.init; // reals are signalling nans by default
creal c = ...;
//c.im = snan; // doesn't work
c = snan + snan * 1i;

assert(isSignallingNan(c.re)); // pass
assert(isSignallingNan(c.im)); // fail

c = snan + cast(ireal)snan; // doesn't work either

I know complex types are scheduled for deprecation but I'm still confused.

"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:

Denis Koroskin wrote:
 For some reason compiler rewrites someComplexVar.re and 
 someComplexVar.im into cast(real)someComplexVar and 
 cast(ireal)someComplexVar respectively, which results in those variables 
 being non-lvalues and me being unable to update either of a properties 
 independently of each other. As one of the consequences, I can't set 
 imaginary part of a complex variable to signalling nan:
 
 real snan = real.init; // reals are signalling nans by default
 creal c = ...;
 //c.im = snan; // doesn't work
 c = snan + snan * 1i;
 
 assert(isSignallingNan(c.re)); // pass
 assert(isSignallingNan(c.im)); // fail
 
 c = snan + cast(ireal)snan; // doesn't work either
 
 I know complex types are scheduled for deprecation but I'm still confused.


I don't know whether the current behaviour is intentional, but in 
std.complex.Complex, which is supposed to replace the built-in types, 
Complex.re and Complex.im are ordinary public member variables.

-Lars