Complex numbers in lib?

Seb seb at wilzba.ch
Tue Jul 28 16:58:51 UTC 2020


On Tuesday, 28 July 2020 at 01:24:16 UTC, sai wrote:
> I remember the reason D has built in complex numbers is because 
> it supposed to give correct results, as mentioned at the bottom 
> here:

Hehe, my guess is that std.complex wasn't written by Walter and 
this special case was overlooked.

See also: 
https://github.com/dlang/phobos/blob/cd2ba0d2c378a893ec0eaefc57b87d0770a1990c/std/complex.d#L345-L347

> So I am curious why the complex class in the library was 
> introduced

Supporting complex numbers requires a lot of work in the frontend.
For many features that D supports one needs to manually maintain 
special cases for complex numbers.
This has led to a lot of bugs and as complex numbers aren't very 
heavily used there are likely many which haven't surfaced yet.

A library solution provides almost the same interface and 
usability to the user. I guess the only missing thing is that 
it's a bit more verbose, but in theory the compiler could lower 
complex numbers to `std.complex` calls.

tl;dr:
- low usage of complex number to justify big complexity in 
compiler
- better maintainability as a library

The current philosophy is that everything that can be done in a 
library, should be done in a library to reduce the burden on the 
compiler.

> and the builtin complex numbers are deprecated now?

Technically they aren't deprecated yet (only discouraged to use). 
There was some work done in Phobos to support the deprecation PR 
for DMD (that's why you get the deprecation message when trying 
to print them), but the DMD deprecation PR stalled:

https://github.com/dlang/dmd/pull/7640

> And how to avoid errors like the above when using the complex 
> library?

3i (builtin) and complex(0, 3) (library) are different types.

To avoid deprecation errors, the `complex` (library) and not the 
to-be-deprecated built-in types should be used.


More information about the Digitalmars-d mailing list