No more implicit conversion real->complex?!

[Rioshin an'Harthen]

"Don Clugston" <dac at nospam.com.au> wrote in message 
news:dvotc1$489$1 at digitaldaemon.com...
> Rioshin an'Harthen wrote:
>>
>> I doubt they'd become that much more complicated. Currently, the DMD 
>> compiler has to look up all the possible implicit conversions, and if 
>> there's more than one possible conversion, error out because it can't 
>> know which one.
>>
>> Now, since it knows the types in question - and the type of the value 
>> being passed to the function, it's not that much more to do, IMHO. 
>> Basically, if it would error with an amiguous implicit conversion, do a 
>> search of the minimum of the possible types that are larger than the 
>> current type. If this doesn't match any type, do the error, otherwise 
>> select the type. A simple search during compile time is all that's 
>> required if we encounter more than one possible implicit conversion, to 
>> select the one that is the smallest of the possible ones.
>
> (a) your scheme would mean that float->cfloat (64 bits) is preferred over 
> float->real (80 bits) on x86 CPUs.

Hmm... yes, a slight problem in my logic. Still fixable, though. Let's 
introduce a concept of "family" into this, with a family consisting of:

A: void
B: char, wchar, dchar
C: bool
D: byte, short, int, long, cent
E: ubyte, ushort, uint, ulong, ucent
F: float, double, real
G: ifloat, idouble, ireal
H: cfloat, cdouble, creal

etc.

Now, allow implicit conversion upwards in a family, and between families 
only if impossible to convert inside the family.

This would fix this problem, but it would introduce a different level of 
complexity into it. It might be worth it, or then again it might not. It's 
for Walter to decide at a later point. I'd like to have implicit conversion 
between real and complex numbers - there's a ton of occasions I've used it, 
so I'm trying to voice some thoughts into the matter on how to preserve 
those.


> (b) since the size of real is not fixed, the result of the function lookup 
> could depend on what CPU it's being compiled for!

True, real is not fixed in size. But according to the D specifications it is 
the "largest hardware implemented floating point size", and I take it to 
mean it can't be less in size than double. If a real and a double is the 
same size, there's no problem, and even less of one if real is larger.


> (c) What if the function has more than one argument?
>
> It might be better to just include a tie-break for the special cases of
> real types -> complex types, and imaginary -> complex. But I think case 
> (c) is a serious problem anyway.
>
> given
> func( real, creal ) // #1
> func( creal, real ) // #2
> func( creal, creal) // #3
>
> should func(7.0, 5.0)
> match #1, #2, or  #3 ?

Well, this is a problem, there's no doubt about it. As I take the example, 
the intention is that at least one of the arguments of the function has to 
be complex, and #1 and #2 are more like optimized versions than #3. This is 
still ambiguous.

If we'd go by symmetry, having it match #3, then the question could be posed 
as:

given
func( real, creal ) // #1
func( creal, real ) // #2

should func( 7.0, 5.0 )
match #1 or #2.

Still, I would go for the symmetrical - if any one parameter is implicitly 
converted, first try a version where as many as possible of the parameters 
are implicitly converted, unless a cast( ) has been used to explicitly mark 
a type. So I say (in this case) match #3 - I may be utterly wrong, but it's 
the feeling I have.


> <genuinequestion>
> And if "none, it's still ambiguous", have we really solved the problem?
> </genuinequestion>

No, we haven't. And probably we never will. But I think we'd be making some 
progress into solving the problem, maybe making it easier for others in the 
long run to be able to get it more right than we have.

<humourous>
Hmm, how about ditching float, double and real, as well as the imaginary 
versions? Only going for the complex types - now that'd be a way to solve 
this problem! ;)
</humourous>