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