No more implicit conversion real->complex?!

[kris]

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?

Suffixes can conceivably be used to disambiguate the utf8/long case, 
yet, surely that same approach could be applied to creal vs real? 
Alternatively, one might argue that suffixes themselves are entirely 
inconvenient. They are certainly not clear to a 'novice' (what with all 
the talk of D as a first language), and can become confusing to an 
'expert' too ~ especially, I imagine, when maintaining someone else's code?

I think what you pointed out here is that type coercion (as it stands) 
should probably only work for a few select types, where it actually 
makes sense. Walter has now changed the compiler to abolish 
type-coercion for real/creal; should this trend not continue to other 
types, where it makes sense to do so? Otherwise, shouldn't the change 
have been to apply suffix-distinction in the cases you talk about?

Unfortunately, this opens up the whole type-selection concern regarding 
arguments of the literal variety, of any type, within D. A concern that 
keeps coming up :-)