Remove complex and imaginary types?

[davidl]

在 Mon, 07 Jan 2008 14:00:38 +0800，Walter Bright  
<newshound1 at digitalmars.com> 写道:

> The issue comes up now and then about why have complex and imaginary  
> types, rather than using structs? All but one of the advantages of  
> having them be core types can be addressed with advancing compiler  
> technology. Getting rid of them will release 6 keywords, and make the  
> core language simpler. Given the increasing complexity of D, this will  
> help.
>
> The remaining advantage is that of imaginary literals, i.e. the i  
> postfix:
>
> 	3 + 5i
>
> Assuming we solve the literal problem, existing code would only need to  
> add:
>
> 	import std.complex;
>
> to acquire complex and imaginary types.

So it's time for implicitCastFrom?

Use of imaginary literals would be limited, I can't think of a possible  
solution to
(1+2i)*(3+5i) without support from current mechanism. Yet, I don't think  
that's a big deal.

I don't see any possible compiler magic can deduce 1+2i firstly implicitly  
cast to a struct. What about the struct not getting any opMul?
How well would the error be diagnosed? And even if the compiler is able to  
fulfill this, that means we prevent another struct/class to have  
implicitCastFrom(creal a) and one of opMul/opAdd/opSub/opDiv at the same  
time.

ireal_struct myirealnumber = 2i; would work as expected by the  
implicitCastFrom magic.
struct ireal_struct
{
implicitCastFrom(creal a)  // and implement cfloat?, cdouble?, for  
different case we get different data size. use a enum to store the number?
{
    static if( compile_time_get_real_part_func(a) != 0 )
      pragma(msg,"You can't cast a non pure imaginary number to pure  
imaginary number.");
    ...
}
...
}

The problem is that the compiler won't be able to accurately report the  
line of code, and not to say which column. static assert won't give you a  
back trace. Also I don't know the compile_time_get_real_part_func? How to  
get the real part or the imaginary part of a number at compile time? seems  
it's not yet possible.

And hopefully, DMD would get the column info in the future as DMC. How to  
get that column info at compile time? This would make the diagnostic  
system becoming complexier. But if we don't implement this in the future,  
we get the diagnostic system inconsistency. Just like at the moment, we  
get some error with line numbers, while some are not.

Currently I can only see three keywords which can be eliminated  
(ireal,ifloat,idouble).

But if we want to eliminate cfloat,cdouble,creal, we come to a problem :  
what's typeof(3+5i)?

Regards,

David


-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/