Bug 692 – rules for assigning to complex types are too strict

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

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.

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

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.

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

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

*** Issue 6006 has been marked as a duplicate of this issue. ***

Closing as WONTFIX as per Andrei and Don's comments.