No more implicit conversion real->complex?!

[kris]

Don Clugston wrote:
> 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 has been a nuisance, but (so far) less than the trouble caused by 
string literals (which is pretty awful)

In retrospect, it's a shame they weren't called utf8, utf16, and utf32 
from the start. Char would have little reason to exist at that point; 
only byte/ubyte.


> 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.

Agreed. Although "annoying" is perhaps is bit light-hearted for what 
happens in reality :-)

> 
> 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?

I wouldn't doubt it. Something similar would probably fix the problem 
with string literals also? (although, I believe there's an easier and 
more consistent way to resolve the latter).