dlang
Remove complex and imaginary types from language in Edition v2024
Add -preview=complex, an option that removes cfloat, cdouble, and creal from the D language.
For C/C++ compatibility, new special enums have been added - and will likely be used for a std.complex.Complex!(T).toNative() function.
Example implementation:
// ABI layout of native complex
struct _Complex(T) { T re; T im; }
// Special enum definitions.
version (Posix)
{
align(float.alignof) enum __c_complex_float : _Complex!float;
align(double.alignof) enum __c_complex_double : _Complex!double;
align(real.alignof) enum __c_complex_long_double : _Complex!real;
}
else
{
align(float.sizeof * 2) enum __c_complex_float : _Complex!float;
align(double.sizeof * 2) enum __c_complex_double : _Complex!double;
align(real.alignof) enum __c_complex_long_double : _Complex!real;
}
// Backwards compatibility aliases
alias cfloat = __c_complex_float;
alias ifloat = float;
alias cdouble = __c_complex_double;
alias idouble = double;
alias creal = __c_complex_long_double;
alias ireal = real;
// Test can still call extern C++ functions.
extern(C++) creal cadd1(creal a);
int main()
{
creal a = creal(1, 0);
auto b = cadd1(a);
version (DigitalMars) // ??? DMD bug with native complex numbers.
assert(b.re == 0 && b.im == 2);
else
assert(b.re == 2 && b.im == 0);
return 0;
}
If I understand correctly, when this switch is enabled, code that uses cfloat, cdouble and creal will instead treat them as float, double, real?
If I understand correctly, when this switch is enabled, code that uses
cfloat,cdoubleandcrealwill instead treat them asfloat,double,real?
No, cfloat, cdouble, and creal will be gone from the language.
However, because some people still need to be able to interface to extern C libraries, some magic enums have been added in order to treat struct { float, float } as a cfloat type for ABI purposes.
When testing this, I have ran into many bugs in DMD though. Which I could infer to mean that nobody can be using complex types in D if there's this many problems with them.
Then why use a preview flag? Preview flags usually add a new feature, whereas for removing features we do a deprecation cycle. Is there something preventing us from going down that path?
Removing a feature is still a new feature... :-)
If complex numbers get removed outright, then the -preview=complex will turn into a -revert=complex for another couple years.
Which I could infer to mean that nobody can be using complex types in D if there's this many problems with them.
Complex native types were a bad idea, and were deprecated long ago so there was no point to fixing bugs in them. Except that they were never actually deprecated.
Is it close to being done?
The implementation is "done", just slowly rolling out the scaffolding for the library support. It would be good to get -transition=complex being enabled by default before this as well, so that complex types are in full deprecation mode.
Which I could infer to mean that nobody can be using complex types in D if there's this many problems with them.
Present in 7 commercial products. We are still using it, and thanks to provide a proper deprecation flag. For us the removal of complex number is not as trivial as people here think it is!
Then why use a preview flag? Preview flags usually add a new feature, whereas for removing features we do a deprecation cycle. Is there something preventing us from going down that path?
We need that preview flag please.
It would be good to get -transition=complex being enabled by default before this as well, so that complex types are in full deprecation mode.
It would be nice to have preview flag become default in more than just 2 months? We. are. using. this.
Preview flags not exactly simple with DUB.
It would be good to get -transition=complex being enabled by default before this as well, so that complex types are in full deprecation mode.
It would be nice to have preview flag become default in more than just 2 months? We. are. using. this.
The transition flag has been in the compiler for a few years now. Phobos is built with it, but druntime isn't because there's still a couple of places still using complex types (rt.typeinfo and rt.memset).
Honestly, even before you chimed in my timeline was approximately around in two years time as per DIP 1013.
Which I could infer to mean that nobody can be using complex types in D if there's this many problems with them.
Present in 7 commercial products. We are still using it, and thanks to provide a proper deprecation flag. For us the removal of complex number is not as trivial as people here think it is!
In case you missed it, you can still pull out native types for ABI purposes (#12167), these magic enums will land in druntime core.stdc.config soon.
And no, it is not trivial, otherwise it would have been done 3 years ago when the process was started. :-)
Rebased, I'll write up a changelog and bring this out of draft phase when #12390 is done.
I don't really understand the point of this. Once we're deprecating imaginary / complex, we wait the 10 releases, then remove them. So why an extra -preview ?
I don't really understand the point of this. Once we're deprecating imaginary / complex, we wait the 10 releases, then remove them. So why an extra
-preview?
Allows introducing new library code that was previously impeded by creal being a keyword ahead of time and verify that it's working.
There is no rush, however, so I'm fine just leaving this pr for 10 releases to remind what needs to be done to initially remove them. There'll be many follow-up PRs to clean up the now dead parts of the AST.
Thanks for your pull request, @ibuclaw!
Bugzilla references
Your PR doesn't reference any Bugzilla issue.
If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.
Testing this PR locally
If you don't have a local development environment setup, you can use Digger to test this PR:
dub run digger -- build "master + dmd#12069"
Original implementation using -preview= has now been replaced with Editions.
FYI @dkorpel