Why D is annoying =P

[Rob T]

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