I guess I'm a little confused… Is the following thinking correct? I can declare a function in two ways:
void foo (reftype @);
void foo (reftype &in);
In the first case, I should be ready to deal with nullptrs. In the second case, nullptr references still exist, but the runtime throws an exception before they reach me, so I don't have to worry about it (too much).
Following up from that, it is recommended (somewhere in the docs) that opEquals is declared as:
bool opEquals (reftype @);
This is great, because if I happen to pass a nullptr I can just deal with it myself. So…
reftype r1, r2;
if (r1 == r2) …
will tell us if r1 and r2 are valid. And this also works:
reftype r1, @r2;
if (r1 == r2) …
No problem, I can deal with the nullptr! But then:
reftype @r1, @r2;
if (r1 == r2) …
This throws a nullptr exception. That is, uhh, not something I would immediately expect from a comparison operator. Is there a way to declare opEquals so that it can deal with both parameters being nullptr?