No more implicit conversion real->complex?!

[Sean Kelly]

kris wrote:
> Don Clugston wrote:
>> kris wrote:
>>
>>> Don Clugston wrote:
>>>
>>>> Norbert Nemec wrote:
>>>>
>>>>> I just notice that as of D 0.150, implicit conversion from
>>>>> real/imaginary to complex does not work any more. I could not make out
>>>>> the message containing the suggestion by Don Clugston, so I'm not sure
>>>>> about the rationale.
>>>>>
>>>>> In any case: if this conversion does not work implicitely any more, I
>>>>> wonder whether I understand the rule which conversions do? 
>>>>> real->complex
>>>>> is possible without ambiguities or loss of information. Why not 
>>>>> make it
>>>>> implicit?
>>>>
>>>>
>>>>
>>>> It's not 100% unambiguous, there are two possible conversions
>>>>     7.2 -> 7.2 + 0i
>>>> and 7.2 -> 7.2 - 0i.
>>>>
>>>> OK, it's not a big deal. But the real problem is that with that 
>>>> implicit conversion in place, overload resolution is a real nuisance.
>>>>
>>>> Consider
>>>> creal sin(creal c);
>>>> real sin(real x);
>>>>
>>>> writefln( sin(3.2) );
>>>>
>>>> Now, 3.2 is a double, so it tries to find sin(double).
>>>> This fails, so it tries implicit conversions.
>>>> Both sin(creal) and sin(real) are possible, so it's ambiguous, and
>>>> compilation will fail.
>>>> Up to now, the only way of overcoming this was to supply seperate 
>>>> functions for float, double, real, and creal arguments. This is 
>>>> clumsy, and becomes impractical once multiple arguments are used.
>>>>
>>>>> I think this is an important issue: in numerics, mixing of real and
>>>>> complex values happens all the time, therefore it should be as 
>>>>> simple as
>>>>> possible.
>>>>
>>>>
>>>>
>>>> I agree. But the implicit conversions were actually making mixing of 
>>>> real and complex functions much more difficult. It would be good to 
>>>> have someone other than me seriously thinking about these issues, 
>>>> and gaining some experience with numerics in D.
>>>
>>>
>>> By this argument, if the overloaded types were char and long (instead 
>>> of creal & real) then D should not allow implicit conversion there?
>>
>>
>> I can't think of many examples where you have overloads of both char 
>> and long. But it's _extremely_ common for complex functions to be 
>> overloads of real functions. Let's not forget that the purpose of 
>> implicit conversions is for convenience. IMHO, real->creal fails to be 
>> convenient, given the D's simple lookup rules.
>>
> 
> Yes, Don, but isn't that a question of extent? You argue, reasonably, 
> for a distinction between creal & real. Surely the same argument can be 
> used to distinguish between a UTF8 char and a signed 64-bit integer? I 
> mean, the latter two are of significantly different type, with quite 
> distinct intent. Isn't it just as inconvenient to have those bumping 
> into each other?

Yes :-)  However, there may be compatibility reasons to support the char 
conversion, as C does as well.

Sean