Remove complex and imaginary types?
davidl
davidl at 126.com
Sun Jan 6 23:52:28 PST 2008
在 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/
More information about the Digitalmars-d
mailing list