Fixing the imaginary/complex mess

[Don]

Walter Bright wrote:
> Don wrote:
>> I don't think anyone expects to be able to divide an integer by an 
>> imaginary, and then assign it to an integer. I was astonished that the 
>> compiler accepted it.
> 
> There actually is a reason - completeness. Mathematically, there is a 
> definite answer to it, so why not fill in all the entries for all the 
> combinations?

In the case complex = int/complex, there's no problem. It's the case int 
= int/complex that doesn't make sense.
And that's fundamentally because cast(real)(2 + 3i) doesn't have a 
definite answer.
There's no mathematical operation to convert a complex number to a real.
Normally, to get a real result, you need to do something like 
multiplying by the complex conjugate. You CAN take the real part of a 
complex number, and you can also take the modulus (which makes a lot of 
sense if you're using polar represantation).

Of course, cast() is not a mathematical operation, it's a D operation, 
so we can define it however we like. But defining it
cast(real)z = z.re;
is an arbitrary decision, which introduces lots of complexity to the 
language, and the many compiler bugs are a consequence.
It's confusing for newbies (there's been questions on D.learn asking, "I 
can get the real part of a complex number with cast(real), but how do I 
get the imaginary part? cast(ireal) gives me an ireal, not a real!").

Since D supports the very nice .re syntax, there's really no reason to 
define cast(real) at all. z.re is better in 100% of use cases. There are 
*NO* use cases for cast(real); any use of cast(real) is a bug. We should 
kill it.