Fixing the imaginary/complex mess

[Georg Wrede]

Don wrote:
> 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.

Walter, could the error message then include "Please use z.re or z.im to 
get the parts, instead of a cast." or something. Otherwise we have to 
explain to all users separately what's going on, /and/ that the omission 
of implementing the cast in D isn't an omission.