No more implicit conversion real->complex?!

[Rioshin an'Harthen]

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

}