unsigned policy (implicit conversions for complex?)

[Bill Baxter]

don wrote:
> 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.

Hmm.  Well maybe in that case there should be a distinction made based 
on context.  Because to me, this being an error is just silly:
    cfloat x = 1.0;

--bb