DIP 52 - Implicit conversions

[Andrei Alexandrescu]

On 12/12/13 6:31 AM, Don wrote:
> On Wednesday, 11 December 2013 at 21:00:19 UTC, Joseph Rushton Wakeling
> wrote:
>> On 11/12/13 13:44, Simen Kjærås wrote:
>>> I've tried to figure out good ways to add some sorely-needed implicit
>>> conversions to the language, but I'm sure there are details that need
>>> to be
>>> ironed out. In other words - destroy!
>>
>> Since you brought up std.complex: some of the issues here are subtle.
>> For example, it's appropriate to allow implicit conversion from
>> numerical => Complex (although this can be done fairly readily by just
>> calling complex(x) where x is a numerical type); it's also appropriate
>> to allow implicit conversion from Imaginary => Complex; but it'd be
>> wrong to allow implicit conversion from numerical => Imaginary.
>>
>> Conversely, I'm not certain whether it'd be appropriate to allow
>> implicit conversion Complex => numerical or Complex => Imaginary, even
>> if the imaginary or real parts respectively were zero.
>
> I don't think Imaginary should exist at all. Mathematically, it's nonsense.
> It's exactly like defining a NegativeInteger. It has horrible
> properties, such as, it's not closed under multiplication!
>
> I don't think there are many applications for pure imaginary numbers, I
> tried to come up with one but failed. Kahan only provides one example in
> his paper, and it's contrived. It eliminates one subtlety but introduces
> far more. In practice it is always far better to just operate directly
> on the real and imaginary parts.

Great. I'm all for keeping it simple :o). Can you fix Kahan's example 
(or class of examples) with a glorious hack and call it a day?

Andrei