unsigned policy (implicit conversions for complex?)

[don]

Bill Baxter Wrote:

> Andrei Alexandrescu (See Website For Email) wrote:
> 
> > Current D botches quite a few of the arithmetic conversions. Basically 
> > all conversions that may lose value, meaning, or precision should not be 
> > allowed implicitly. Walter is willing to fix D in accordance to that 
> > rule, which would yield an implicit conversion graph as shown in:
> > 
> > http://erdani.org/d-implicit-conversions.pdf
> > 
> 
> I notice the graph doesn't include complex types.
> Is there any reason why float shouldn't be automatically converted to 
> cfloat?
> 
> --bb

Yes.
It used to. It was removed at my request. The problem is, that it introduces *two* directions that float can be converted to.

float -> double -> real
and
float -> cfloat.

Suppose you have:
void func(real) {}
void func(creal){}

and then you type:
func(3.1);

What happens? 3.1 is a double, not a real, so there's no exact match. So the compiler has an ambiguous conversion, and the code won't compile.

Consequence: under the old rules, if you provide both real and complex overloads for a function, you must provide float, double, and real versions.
If the function has multiple arguments, you must provide all combinations. It's untenable.

Note that the same thing happens if you had int-> double conversions:
func(long)
func(real)

--> you must provide func(int) and func(short) variants.

If would be OK if there was a rule that 'lengthening' conversions
char > wchar > dchar, byte > short> int > long, float>double>real, ...
were preferred over meaning-changing conversions
(char > byte, wchar > ushort, int > double, ....)

but that would require another level of matching in the lookup rules.