References in D

[Franciszek Czekała" <home at valentimex.com>]

On Saturday, 6 October 2012 at 04:10:28 UTC, Chad J wrote:
> On 10/05/2012 08:31 AM, Regan Heath wrote:
>> On Fri, 05 Oct 2012 05:19:13 +0100, Alex Burton
>> <alexibureplacewithzero at gmail.com> wrote:
>>
>>> On Saturday, 15 September 2012 at 17:51:39 UTC, Jonathan M 
>>> Davis wrote:
>>>> On Saturday, September 15, 2012 19:35:44 Alex Rønne 
>>>> Petersen wrote:
>>>>> Out of curiosity: Why? How often does your code actually 
>>>>> accept null as
>>>>> a valid state of a class reference?
>>>>
>>>> I have no idea. I know that it's a non-negligible amount of 
>>>> the time,
>>>> though
>>>> it's certainly true that they normally have values. But null 
>>>> is how you
>>>> indicate that a reference has no value. The same goes for 
>>>> arrays and
>>>> pointers.
>>>> Sometimes it's useful to have null and sometimes it's useful 
>>>> to know
>>>> that a
>>>> value can't be null. I confess though that I find it very 
>>>> surprising
>>>> how much
>>>> some people push for non-nullable references, since I've 
>>>> never really
>>>> found
>>>> null to be a problem. Sure, once in a while, you get a null
>>>> pointer/reference
>>>> and something blows up, but that's very rare in my 
>>>> experience, so I
>>>> can't help
>>>> but think that people who hit issues with null pointers on a 
>>>> regular
>>>> basis are
>>>> doing something wrong.
>>>>
>>>> - Jonathan M Davis
>>>
>>> In my experience this sort of attutide is not workable in 
>>> projects
>>> with more than one developer.
>>
>> Almost all my work is on projects with multiple developers in 
>> C/C++ and
>> making extensive use of null.
>>
>>> It all works OK if everyone knows the 'rules' about when to 
>>> check for
>>> null and when not to.
>>
>> As every good C/C++ developer does. The rule is simple, always 
>> check for
>> nulls on input passed to "public" functions/methods. What you 
>> do with
>> internal protected and private functions and methods is up to 
>> you (I use
>> assert).
>>
>>> Telling team members that find bugs caused by your null 
>>> references
>>> that they are doing it wrong and next time should check for 
>>> null is a
>>> poor substitute for having the language define the rules.
>>
>> Having language defined rules is a nice added /bonus/ it 
>> doesn't let you
>> off the hook when it comes to being "null safe" in your code.
>>
>>> A defensive attitude of checking for null everywhere like I 
>>> have seen
>>> in many C++ projects makes the code ugly.
>>
>> That's a matter of opinion. I like to see null checks at the 
>> top of a
>> function or method, it makes it far more likely to be safe and 
>> it means
>> I can ignore the possibility of null from then on - making the 
>> code much
>> cleaner.
>>
>> R
>>
>
> I find this to be very suboptimal at the least.
>
> This prevents null values from traveling "up" the stack, but 
> still allows them to move "down" (as return values) and allows 
> them to survive multiple unrelated function calls.
>
> It catches null values once they've already ended up in a place 
> they shouldn't be.  Too late.
>
> Nulls can also be placed into variables within structs or 
> classes that then get passed around.  Checking for those can 
> require some complex traversal: impractical for casual one-off 
> checks at the start of a function in some cases.
>
> void main()
> {
> 	void* x = a(b());
> 	c();
> 	while(goobledegook)
> 	{
> 		x = p();
> 		d(x);
> 	}
> 	e(x); /+ Crash! x is null. +/
> }
>
> Where did x's null value come from?  Not a. Not p; the while 
> loop happened to be never executed.  To say "b" would be 
> closer, but still imprecise.  Actually it was created in the 
> q() function that was called by u() that was called by b() 
> which then created a class that held the null value and was 
> passed to a() that then dereferenced the class and returned the 
> value stored in the class that happened to be null.  nulls 
> create very non-local bugs, and that's why they frustrate me to 
> no end sometimes.
>
> What I really want to know is where errant null values come 
> FROM.
>
> I also want to know this /at compile time/, because debugging 
> run-time errors is time consuming and debugging compile-time 
> errors is not.
>
> The above example could yield the unchecked null assignment at 
> compile time if all of the types involved were typed as 
> non-nullable, except for the very bare minimum that needs to be 
> nullable.  If something is explicitly nullable, then its 
> enclosing function/class is responsible for handling null 
> conditions before passing it into non-nullable space.
>  If a function/class with nullable state tries to pass a null 
> value into non-nullable space, then it is a bug.  This contains 
> the non-locality of null values as much as is reasonably 
> possible.
>
> Additionally, it might be nice to have a runtime nullable type 
> that uses its object file's debugging information to remember 
> which file/function/line that its null value originated from 
> (if it happens to be null at all).  This would make for some 
> even better diagnostics when code that HAS to deal with null 
> values eventually breaks and needs to dump a stack trace on 
> some poor unsuspecting sap (that isn't me) or ideally sends an 
> email to the responsible staff (which is me).

>returned the value stored in the class that happened to be null.

Happened? "I was driving carefully and then it happened I drove 
into the tree, officer." 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. 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.

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. Insistance on formal tools is a 
misunderstanding that leads to design bloat and eventually 
failure (Ada).

D competes directly with C++ as Ada did before. Ada drowned under 
the weight of its "safety" and so will D if it goes the same 
route. The only thing needed now are mature compilers and good 
systems API integration. If anything I would rather consider 
removing features from the language than adding them.