On Monday, 3 February 2014 at 22:18:35 UTC, Jonathan M Davis wrote:
> For it to know, it would have to examine the body of foo (which it doesn't
> necessarily have the code for under C's compilation model - which D uses), and
> even if it did that wouldn't be enough e.g.
>
> int* foo()
> {
>     return "/etc/foo".exists ? new int : null;
> }
>
> The compiler could flag that as _possibly_ returning null and therefore the
> previous code _possibly_ dereferencing null, but it can't know for sure.

If null is an invalid value to assign to a pointer, then there's no issue.

int* foo()
{
    //Error: cannot implicitly convert typeof(null) to type int*
    return "/etc/foo".exists ? new int : null;
}

This is fantastic news, Andrei!

It's all about provably correct code like Walter often brings up on his talks.

If/When this arrives, D will become an even more suitable replacement for safety critical languages like Ada.

On 2/3/2014 12:46 PM, Ary Borenszweig wrote:
> On 2/3/14, 5:56 AM, Walter Bright wrote:
>> On 2/3/2014 12:00 AM, Uranuz wrote:
>>> At the current state OS send SEGFAULT message and I can't
>>> even get some info where is the source of problem.
>>
>> 1. Compile with symbolic debug info on (-g switch)
>>
>> 2. Run under a debugger, such as gdb
>>
>> 3. When it seg faults, type:
>>
>>     bt
>>
>> and it will give you a "backtrace", i.e. where it faulted, and the
>> functions that are on the stack.
>
> You keep missing the point that when the segfault happens you might have no idea
> how to reproduce it. You don't even know where it happens. So it's not that easy
> to reach point 3.

The first step is ensuring that people know how to use a debugger. The second step, for the case you mentioned, is figuring out how to attach a debugger to a crashed process.


> If a null access raises an exception, you immediately get the backtrace and that
> can help you understand why it happened.

I agree that's certainly more convenient, but I was addressing the "I can't" issue. The message did not have enough information to determine if he was having trouble with a basic issue or a more advanced case.

On Monday, 3 February 2014 at 22:23:52 UTC, Meta wrote:
> If null is an invalid value to assign to a pointer, then there's no issue.
>
> int* foo()
> {
>     //Error: cannot implicitly convert typeof(null) to type int*
>     return "/etc/foo".exists ? new int : null;
> }

Only cross abstraction boundaries is sufficient.

On Monday, 3 February 2014 at 23:34:59 UTC, deadalnix wrote:
> On Monday, 3 February 2014 at 22:23:52 UTC, Meta wrote:
>> If null is an invalid value to assign to a pointer, then there's no issue.
>>
>> int* foo()
>> {
>>    //Error: cannot implicitly convert typeof(null) to type int*
>>    return "/etc/foo".exists ? new int : null;
>> }
>
> Only cross abstraction boundaries is sufficient.

Can you explain?

On Tuesday, 4 February 2014 at 01:09:52 UTC, Meta wrote:
> On Monday, 3 February 2014 at 23:34:59 UTC, deadalnix wrote:
>> On Monday, 3 February 2014 at 22:23:52 UTC, Meta wrote:
>>> If null is an invalid value to assign to a pointer, then there's no issue.
>>>
>>> int* foo()
>>> {
>>>   //Error: cannot implicitly convert typeof(null) to type int*
>>>   return "/etc/foo".exists ? new int : null;
>>> }
>>
>> Only cross abstraction boundaries is sufficient.
>
> Can you explain?

void foo() {
     Widget w = null; // OK
     w.foo(); // Error w might be null.

     w = new Widget();
     w.foo(); // OK

     if(condition) {
         w = null;
     }

     w.foo(); // Error

     if(w !is null) {
         w.foo(); // OK
     }

     bar(w); // Error, w might be null=
     return w; // Error, w might be null
}

On Monday, February 03, 2014 22:23:51 Meta wrote:
> On Monday, 3 February 2014 at 22:18:35 UTC, Jonathan M Davis
> 
> wrote:
> > For it to know, it would have to examine the body of foo (which
> > it doesn't
> > necessarily have the code for under C's compilation model -
> > which D uses), and
> > even if it did that wouldn't be enough e.g.
> > 
> > int* foo()
> > {
> > 
> > return "/etc/foo".exists ? new int : null;
> > 
> > }
> > 
> > The compiler could flag that as _possibly_ returning null and
> > therefore the
> > previous code _possibly_ dereferencing null, but it can't know
> > for sure.
> 
> If null is an invalid value to assign to a pointer, then there's no issue.

Yes, but I wasn't talking about non-nullable pointers. I was talking about how in the general case, it's impossible to determine at compile time whether a nullable pointer is null and that it's therefore impossible (in the general case) to determine at compile time whether dereferencing a nullable pointer will attempt to dereference null. Non-nullable pointers side-steps the issue entirely.

- Jonathan M Davis

On Sunday, February 02, 2014 17:41:58 Meta wrote:
> > 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
> 
> Ideally you'd be using them wherever you use objects and pointers, as they'd be the default.

I truly hope that that's never the case. Adding non-nullable references to the language is one thing; making them the default is quite another, and making them the default would break existing code. And given Walter's normal stance on code breakage, I'd be very surprised if he were in favor of making non- nullable references or pointers the default.

- Jonathan M Davis

On 2/3/14, 9:09 PM, Jonathan M Davis wrote:
> I truly hope that that's never the case. Adding non-nullable references to the
> language is one thing; making them the default is quite another, and making
> them the default would break existing code. And given Walter's normal stance
> on code breakage, I'd be very surprised if he were in favor of making non-
> nullable references or pointers the default.

We are considering making non-nullables the default, @nullable to mark optionally null objects, and enable the related checks with an opt-in compiler flag.

Andrei

On Tuesday, 4 February 2014 at 06:03:14 UTC, Andrei Alexandrescu wrote:
> On 2/3/14, 9:09 PM, Jonathan M Davis wrote:
>> I truly hope that that's never the case. Adding non-nullable references to the
>> language is one thing; making them the default is quite another, and making
>> them the default would break existing code. And given Walter's normal stance
>> on code breakage, I'd be very surprised if he were in favor of making non-
>> nullable references or pointers the default.
>
> We are considering making non-nullables the default, @nullable to mark optionally null objects, and enable the related checks with an opt-in compiler flag.
>
> Andrei

That would be awesome. The breakage involved, is quite high however.