http://d.puremagic.com/issues/show_bug.cgi?id=692

           Summary: rules for assigning to complex types are too strict
           Product: D
           Version: 0.177
          Platform: All
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: wbaxter@gmail.com


//You can assign ints and floats and doubles to a double with no
//problem.  Even arrays work.
void test1() {
    // All ok
    double a = 0;
    double b = 0.0;
    double c = 0.0f;
    double[] d = [0];
    double[] e = [0.0];
    double[] f = [0.0f];
}

//But there's very little that can be assigned to a cdouble:
void test2()
{
    // All errors
    cdouble a = 0;
    cdouble b = 0i;
    cdouble c = 0.0;
    cdouble d = 0.0f;
    cdouble e = 0.0fi;
    cdouble[] f = [0];
}

//Yet, it is ok to add many things to a cdouble.
void test3()
{
    // All ok:
    cdouble a = 0+0i;
    cdouble b = a + 0;
    cdouble c = a + 0i;
    cdouble d = a + 0.0;
    cdouble e = a + 0.0f;
    cdouble f = a + 0.0fi;
}


I don't see any good reason for this strictness.  I suspsect nobody's complained simply because few current users actually touch complex types.

Real world impact:
In writing a generic BLAS/LAPACK-backed nd-array class I find that many of my
generic test cases have to contain sillyness like:
        T z = cast(T)0;
        A = [[z+ 5, z+ 1, z+ 2],
             [z+ 3, z+ 4, z+ 5],
             [z+ 6, z+ 7, z+ 8]];
        x =  [z+ 1, z+ 2, z+ 3];
        b = mult(A,x);

just to handle complex types without generating compiler errors.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=692


wbaxter@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement




------- Comment #1 from wbaxter@gmail.com  2006-12-16 23:28 -------
Whoops, meant this to be an enhancement request, since I don't think the spec actually says anywhere what should happen when an int or float is assigned to a complex type.  At least I couldn't find it.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=692





------- Comment #2 from thomas-dloop@kuehne.cn  2006-12-29 18:31 -------
The rules might seem too strict for the casual user, if you however implement a lot of complex math they make debugging a lot easier.

The current rules for implicit assignment:
1) another complex or 2) and operation involving "real" and "imaginary".


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=692


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |andrei@metalanguage.com
            Version|0.177                       |D1
         AssignedTo|nobody@puremagic.com        |bugzilla@digitalmars.com


--- Comment #3 from Andrei Alexandrescu <andrei@metalanguage.com> 2010-11-26 13:31:34 PST ---
Marking this as D1 only as D2 will only use library complex types. I think this is a wontfix as D1 is frozen, but will leave the decision to Walter.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=692


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #4 from bearophile_hugs@eml.cc 2010-11-26 14:36:48 PST ---
This is not the right place to discuss this, but I remember a discussion about
removing the implementation of complex numbers (and move it into Phobos) and
part of their syntax (ireal, ifloat, etc), but to keep complex literals in D2
(like a + 0.0fi).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=692


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #5 from Don <clugdbug@yahoo.com.au> 2010-11-26 22:17:30 PST ---
> I don't see any good reason for this strictness.
There is a good reason. It was a deliberate decision.
I do not know how the rules could be weakened, without major changes to the
lookup rules.

Originally, the test cases did compile. But the problem is, with the broken implicit conversion rules we've inherited from C, it interferes with function overloading in a horrible way.

Consider:
void foo(real x);

Then you add
void foo(creal x);

And suddenly foo(7.0); doesn't compile any more.

The implicit conversions real -> creal were removed for this reason. It's the lesser of two evils.

Now, I've been planning a proposal for changing the implicit conversion rules for numeric literals, and possibly that make this possible as well. But it's a big change, even for D2.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=692



--- Comment #6 from kennytm@gmail.com 2011-05-15 09:33:09 PDT ---
*** Issue 6006 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------