No more implicit conversion real->complex?!

Don Clugston dac at nospam.com.au
Tue Mar 21 02:34:53 PST 2006


Regan Heath wrote:
> On Tue, 21 Mar 2006 00:15:37 -0800, kris <foo at bar.com> 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?
> 
> You can disambiguate char and long by using an "IntegerSuffix" eg.
> 
> void foo(char c) {}
> void foo(long c) {}
> 
> void main()
> {
>     foo(5L);
> }
> 
> Is the same true for real and creal?

Yes. But IMHO, it is ridiculous to expect user code to write

sin(2L);
instead of sin(2);
just because std.math includes sin(creal).
(It could be a high school student, who's never heard of complex numbers!).



More information about the Digitalmars-d mailing list