No more implicit conversion real->complex?!

[Don Clugston]

Rioshin an'Harthen wrote:
> "Don Clugston" <dac at nospam.com.au> wrote in message 
> news:dvobhe$2cm6$1 at digitaldaemon.com...
>> 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.
> 
> version(delurk)
> {
> 
> I've been thinking about this ever since the last discussion about this, and 
> believe there might be a better solution to the problem at hand than 
> disabling real -> creal implicit conversions.
> 
> Since the compiler knows the storage requirements of the different types, 
> and if multiple implicit conversions are possible (e.g. the above mentioned 
> sin( creal ) and sin( real )), why not make the compiler choose the one with 
> the least storage requirement (i.e. changing the original number the least).
> 
> So if we have
> 
> creal sin( creal c );
> real sin( real r );
> 
> writefln( sin( 3.2 ) );
> 
> as above, the 3.2 is according to specs a double, and we don't find double 
> sin( double d ) anywhere, we try implicit conversions. Now, we have two 
> options: creal sin( creal c ) and real sin( real r ). The storage 
> requirement of creal is larger than that of real, so conversion to real 
> changes the original double less than conversion to creal. Thus, the 
> compiler chooses to convert it into real.
> 
> Naturally, we can help the compiler make the choice:
> 
> writefln( sin( cast( creal ) 3.2 ) );
> 
> would naturally pick the creal version (since 3.2 has been cast to it).
> 
> What are your thoughts about this? Could this work? And if this could, 
> should this be added to the D specifications?
> 
> }

This would mean the lookup rules become more complicated. I think Walter 
was very keen to keep them simple.