On Sunday, 2 February 2014 at 03:45:06 UTC, Andrei Alexandrescu wrote:
> On 2/1/14, 7:35 PM, deadalnix wrote:
>> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
>
> Whoa, thanks. So the compiler figures null pointer dereference in C is undefined behavior, which means the entire program could do whatever if that does happen.
>
> Andrei

As far as I have understood previous posts, it is even worse than that - LLVM optimiser assumes that C semantics whatever high-level language is.

deadalnix is that true?

On 02/02/2014 04:39 AM, Jonathan M Davis wrote:
> I'm not sure how I feel about that, particularly since I haven't seen such
> data myself. My natural reaction when people complain about null pointer
> problems is that they're sloppy programmers (which isn't necessarily fair, but
> that's my natural reaction).

There is no such thing as 'naturality' that is magically able to justify personal attacks in a technical discussion, even if qualified.

> I pretty much never have problems with null
> pointers and have never understood why so many people complain about them.

I guess it is usually some combination of:

Some projects feature more than one programmer.
Hard data.
Aesthetics. (The situation does not have to be unbearable in order to improve it!)

On Sunday, February 02, 2014 12:52:44 Timon Gehr wrote:
> On 02/02/2014 04:39 AM, Jonathan M Davis wrote:
> > I'm not sure how I feel about that, particularly since I haven't seen such data myself. My natural reaction when people complain about null pointer problems is that they're sloppy programmers (which isn't necessarily fair, but that's my natural reaction).
> 
> There is no such thing as 'naturality' that is magically able to justify personal attacks in a technical discussion, even if qualified.

Would you prefer that I had said "initial reaction" or "gut reaction?" I'm just saying that that's how I tend to feel when I see complaints about null pointers. I have never accused anyone of anything or otherwise attacked them because they complained about null pointers. That _would_ be rude.

> The situation does not have to be unbearable in order to improve it!

True, but I don't even agree that null pointers are that big a deal in the first place. If we really want to add non-nullable pointers or references to the language, then we can. I don't think that that's necessarily a bad idea. But I doubt that I'll use them often, and I do think that the whole issue is frequently blown out of proportion.

- Jonathan M Davis

On Sunday, 2 February 2014 at 12:42:47 UTC, Jonathan M Davis wrote:
> But I doubt that I'll use them often, and I do think that the whole issue is
> frequently blown out of proportion.
>
> - Jonathan M Davis

I agree that there is no much benefit in opt-in null-free pointers. But if making those opt-out would have been possible, I'd love it. Breaks every single D program out there though.

On 01/02/2014 22:05, Adam D. Ruppe wrote:
> On Saturday, 1 February 2014 at 18:58:11 UTC, Andrei Alexandrescu wrote:
>>     Widget w = fetchWidget();
>>     if (w)
>>     {
>>         ... here w is automatically inferred as non-null ...
>>     }
>
> A library solution to this exists already:
>
> Widget wn = fetchWidget();
> if(auto w = wn.checkNull) {
>     // w implicitly converts to NotNull!Widget
> }

I read your recent post about this, it was interesting. But I don't think you can disallow this:

    auto cn = checkNull(cast(C)null);
    NotNull!C nn = cn;

obj2 is then null, when it shouldn't be allowed.

On 02/02/2014 13:18, Nick Treleaven wrote:
>      auto cn = checkNull(cast(C)null);
>      NotNull!C nn = cn;
>
> obj2 is then null, when it shouldn't be allowed.

Oops, I meant nn, not obj2.

On Sunday, 2 February 2014 at 13:18:19 UTC, Nick Treleaven wrote:
> I read your recent post about this, it was interesting. But I don't think you can disallow this:
>
>     auto cn = checkNull(cast(C)null);
>     NotNull!C nn = cn;
>
> obj2 is then null, when it shouldn't be allowed.

It wouldn't be null - it would be a runtime assertion failure (except in release mode, when it would indeed be null). I think that's OK.

Two reasons this is an improvement anyway:

1) The error message of "cannot implicitly convert cn of type C to nn of type NotNull!C" made you realize there's a potential problem here and attempt a fix.

That's why checkNull is there in the first place - it made you consider the problem. Your fix isn't really right, but at least now it should be obvious why.

2) The assertion failure happens right there at the assignment point (the assert is in NotNull's constructor) instead of at the use point. So when it fails at runtime, you don't have to work backwards to figure out where null was introduced, it points you straight at it and it won't be too hard to see that cn wasn't properly checked.


Maybe not perfect, but I really think it is good enough and an improvement.... if people actually use NotNull!T in their functions and structures in the first place.

On Sunday, 2 February 2014 at 13:15:42 UTC, Dicebot wrote:
> I agree that there is no much benefit in opt-in null-free pointers. But if making those opt-out would have been possible, I'd love it. Breaks every single D program out there though.

This isn't necessarily so bad. My biggest chunk of code that uses classes is probably my dom.d.... and there's only... I think six functions in there that can return null, and only one property that can be null. (In fact, I think like 1/5 of the lines in there are contracts and invariants relating to null anyway. Once I was getting segfaults because of a corrupted tree and that's ultimately how I tracked it down.)

So if "Element" were changed to be not null by default, the majority of the program should still compile! Then it is a simple case of looking at the compiler errors complaining about assigning null and throw in the Nullable! thingy which shouldn't take that long.


Code like

auto a = new A();
a.foo();

needn't break.


Really, I think it would be likely to find more bugs, or at least save time writing dozens of contracts - it would be the "worth it" kind of breakage.

On 02/02/2014 01:42 PM, Jonathan M Davis wrote:
> On Sunday, February 02, 2014 12:52:44 Timon Gehr wrote:
>> On 02/02/2014 04:39 AM, Jonathan M Davis wrote:
>>> I'm not sure how I feel about that, particularly since I haven't seen such
>>> data myself. My natural reaction when people complain about null pointer
>>> problems is that they're sloppy programmers (which isn't necessarily fair,
>>> but that's my natural reaction).
>>
>> There is no such thing as 'naturality' that is magically able to justify
>> personal attacks in a technical discussion, even if qualified.
>
> Would you prefer that I had said "initial reaction" or "gut reaction?"

That's completely missing the point. "No such thing as".

> I'm just saying that that's how I tend to feel when I see complaints about null
> pointers.

Sure. Assuming a basic amount of honesty, people _always_ post their own opinions. To say it as clearly as I can: Please don't feel that way. It is completely unjustified.

> I have never accused anyone of anything  or otherwise attacked them
> because they complained about null pointers.

I have wasted some time trying to figure out the basis of this claim.

> That _would_ be rude.
> ...

We agree on this point.

On Sunday, 2 February 2014 at 13:55:11 UTC, Adam D. Ruppe wrote:
> On Sunday, 2 February 2014 at 13:15:42 UTC, Dicebot wrote:
>> I agree that there is no much benefit in opt-in null-free pointers. But if making those opt-out would have been possible, I'd love it. Breaks every single D program out there though.
>
> This isn't necessarily so bad. My biggest chunk of code that uses classes is probably my dom.d.... and there's only... I think six functions in there that can return null, and only one property that can be null. (In fact, I think like 1/5 of the lines in there are contracts and invariants relating to null anyway. Once I was getting segfaults because of a corrupted tree and that's ultimately how I tracked it down.)
>
> So if "Element" were changed to be not null by default, the majority of the program should still compile! Then it is a simple case of looking at the compiler errors complaining about assigning null and throw in the Nullable! thingy which shouldn't take that long.
>
>
> Code like
>
> auto a = new A();
> a.foo();
>
> needn't break.
>
>
> Really, I think it would be likely to find more bugs, or at least save time writing dozens of contracts - it would be the "worth it" kind of breakage.

I think it's safe to assume that you - being a supporter of the non-null movement - write your own code in a way that tries to avoid the usage of null as much as possible. Other people - like me - treat null as a valid value. If I have a class\struct `Foo` with a member field `bar` of type `Bar`, and an instance of `Foo` named `foo` that happens to have no `Bar`, I'll not add an extra boolean field just to indicate that `foo` has no `Bar` - I'll simply set `foo.bar` to null!

And I'll use the fact that null is D is false and the `if(auto foobar=foo.bar)` will only enter the block if `foo.bar` is not null, and `foobar` will only be declared in that block, when it's guaranteed to not be null.

And I'll use the fact that UFCS works perfectly fine when the first argument is null to build functions that accept `Bar` as first argument and do the null checking internally(if it's needed!) and safely call them on `foo.bar`.

So yea, your code won't break. That doesn't mean other code won't break.