On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote:
Which parts in dlang don't you use and why?
There is one feature (actually a mix of features) I'd be happy
not to use, but it is not possible: I call it autoreals, because
it resembles somewhat the idea behind autodecoding - in both
cases the compiler (or Phobos) does something automatically that
you cannot avoid and sometimes causes real headache, but which
you could do easily yourself if it were not done automatically):
What I'm talking about is
- reals being differently implemented on different computers
- reals being internally used for computation and intermediate
storage
- reals being automatically used in CTFE (and reals in CTFE might
differ from the reals at runtime)
All together this ends in generic code (for example in libraries)
behaving more or less like a random generator; at least it feels
like this.
I would be able to cope with the first point by either not using
reals at all or `static if` to generate separate code for every
version. But together with the other two "features" reals cannot
be ignored anymore. You cannot even assume a function with return
type double to return a double. So to be sure to have a double,
when a double is needed you need to do stuff like
```
double d = some_fun();
ulong tmp = *cast(ulong*) &d;
tmp ^= 12543;
/* maybe here some more ugly stuff that doesn't change the value
until it is enough to trick the optimizer */
tmp ^= 12543;
d = *cast(double*) &tmp;
```
Even worse with CTFE, where you get values that are neither NaN,
nor infinity but larger then `<type>.max`. And you cannot even
use `static if` to find out which reals are used in CTFE, because
CTFE might use different reals or reals on an other platform or
whatever. So to be able to find out which real you use, you need
to add more ugly code like
```
if (__ctfe)
{
if (real.max + 1 != real.infinity && real.max + 10 - 20 <
real.max)
{
...
}
else
{
}
}
```
Finally you end up writing several hundred lines of code for
something that would have fitted in one line without autoreals;
probably you would prefer to write a library (using heavy amount
of `asm` parts) with types `Float` and `Double` that is just
doing what float and double are normally supposed to do.
What I really dislike about this is, that you have no means to
escape from it, while the other way round it would be easy: If
you really want to use reals instead of double, you could just
use reals...
