No more implicit conversion real->complex?!

[Don Clugston]

kris wrote:
> 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

I think you're right. I think the "C compatibility" argument is relevant 
only for cases where changes would be very common and hard to track down.
(FWIW, I've converted the Cephes math libraries from C to D. In every 
case, the tighter D language rules improved the code).

I haven't done much work with char/wchar/dchar in D, so I don't have 
much idea of how troublesome the implicit conversions are. Undoubtedly 
you have the most experience here. If you're also finding them to be a 
nuisance rather than a convenience, we should

It does seem to me that implicit widening conversions are nearly always 
helpful, but those ones that change the semantics (wchar->short, 
real->creal, etc) seem much more likely to be annoying. I particularly 
dislike conversions that silently insert code.

The suggestion was made to have two levels of implicit conversion, 
roughly similar to the promotion rules, ie:

* exact match
* match with implicit widening conversions
* match with implicit semantic-changing conversions.

Would this improve the situation for char/int conversions?