References in D

Timon Gehr timon.gehr at gmx.ch
Sat Oct 6 03:38:23 PDT 2012


On 10/06/2012 10:18 AM, "Franciszek Czekała" <home at valentimex.com>" wrote:
> Every function should define its interface, its contract
> with the outside world. If a() function returns a pointer it is a part
> of the contract whether it can be null.

The default should be it can't be null. Why would it be null?

> Two possibilities:
>
> A) The contract says it can be null. Then it is your duty to check for
> null. Period. Learn to read the signs before you start driving. You
> assinged the value without checking, it is your fault, not a()'s, not
> the language's.
>

It does not matter whose fault it is. The tree/car/software is broken
already. Google 'automatic braking system'.

> B) The description of a() says the return value cannot be null. Then a()
> should check its return value before returning or make otherwise sure it
> is not null. If it returns null it is a bug. One of the infinite number
> of possible bugs that can happen. Again it is not the problem of the
> language. The problem of divergence of specification and code is a human
> problem that cannot be solved formally.

If the contract does not have to talk about null values when they are
unimportant, the problem does not even occur.


More information about the Digitalmars-d mailing list