On Sunday, 28 October 2012 at 05:28:20 UTC, H. S. Teoh wrote:
I have to say I was surprised to find out about this after I
started
using D; after first reading TDPL, I had the impression that it
was
supposed to do the "right thing" (and the right thing being ==
on each
field, which I assumed the compiler would optimize into a
bitwise
compare where possible).
Let's fix this.
There is a problem with floating point memebers, since nan values
will always compare false.
There's other things in D that bother me, such as how struc
pointers are managed, where they sometimes behave exactly like
class references, but not always. The inconsistent behaviour is a
trap for the programmer to fall into, and it leads to subtle hard
to find errors.
For example:
struct S
{
int a;
~this() {}
}
class C
{
int a;
~this() {}
}
// identical behaviour
auto Sp = new S;
auto Cr = new C;
// identical behaviour
writeln(Sp.a);
writeln(Cr.a);
// identical behaviour
auto Sp2 = Sp;
auto Cr2 = Cr;
writeln(Sp2.a);
writeln(Cr2.a);
// ?
assert(Sp2 == Sp);
assert(Cr2 == Cr);
// different behaviour!
clear(Sp);
clear(Cr);
Last two line compile OK, but clear(Sp) does not invoke the
destructor while clear(Cr) does. clear(*Sp) works, but why allow
clear(Sp) if it's a pointless operation? Is this a bug in the
compiler or with the language design?
Subtle differences like this are very nasty. The code should
behave identically for both the struct pointer and the class
reference, and if this is not poosible for some obscure reason,
then the compiler should fail at the clear(Sp) line.
If I invoke with clear(*Sp) it works, but the inconsistency makes
template code that takes in both a struct or a class impossible
to do (or at best needlessly difficult to do).
--rt
