No more implicit conversion real->complex?!

[kris]

Sean Kelly wrote:
> 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

Aye. There's always some excuse for a lack of consistency :-)

Even then, one might argue that "compatability" is actually there in 
name only. Why would anyone convert a C program to D? I've yet to see an 
extensive example of that; no doubt due to the extensive 
/incompatability/ of D with .h files (in truth, I haven't seen any examples)

Thus the nobility of "C compatability" is perhaps just a bit thin? 
Wouldn't it be nice to tidy some of this up while the opportunity 
presents itself?

- Kris