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.
