On 1/19/2014 4:20 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> If you take a theoretical position (which I think you do)

Please set such statements against my assertion that Boeing follows the principles I outlined in practice, and very successfully.

On 01/19/2014 01:03 PM, Michel Fortin wrote:
> Actually, 'A?' would implicitly convert to 'A' where the compiler can
> prove control flow prevents its value from being null.

I think the type should be upgraded. i.e.:

> So you can
> dereference it in a branch that checked for null:
>
>      class A { int i; void foo(); }
>      void bar(A a); // non-nullable parameter
>
>      void test(A? a, A? a2)
>      {
>          a.i++; // error, 'a' might be null
>          a.foo(); // error, 'a' might be null
>          bar(a); // error, 'a' might be null
>
>          if (a)
>          {
               static assert(is(typeof(a)==A));
>              a.i++; // valid [...]
>              a.foo(); // valid [...]
>              bar(a); // valid [...]
>          }
>      }

On Sunday, 19 January 2014 at 14:23:44 UTC, Paolo Invernizzi wrote:
>> However, in a compiler you can defer to "the pilot" (compiler) so that is generally easier. In a server you can't.
>
> I'm trying to understand your motivations, but why in a server you can't? I still can't grasp that point.

It was a typo: However, in a compiler you can defer to "the pilot" (programmer) so that is generally easier. In a server you can't.

On Sunday, 19 January 2014 at 14:14:11 UTC, Paolo Invernizzi wrote:
> Having had heavy experience with Python, and having used D since D1, I would tell the contrary, that's easier to handle null exception with D.

Leaving dynamic vs non-dynamic aspects aside, why do you find null dereferencing easier to handle (i.e. debug) in D than in Python?

On Sunday, 19 January 2014 at 19:55:34 UTC, Walter Bright wrote:
> On 1/19/2014 4:20 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> If you take a theoretical position (which I think you do)
>
> Please set such statements against my assertion that Boeing follows the principles I outlined in practice, and very successfully.

Would they even consider using D? Are you referring to a niche for which D is not suited? In most situations you cannot afford to develop a program to the point where it is 100% bug free, let alone develop 2 independent versions of the spec to 100% bug free. This is a very narrow niche.

And it isn't even relevant, because crash-and-burn-on-null is still an option with voluntary recovery mechanisms.

And as I pointed out, you wouldn't use zero as a null value if safety and debugging is your prime concern. You would use a more "secure" bitpattern (i.e. harder to arrive at by accident), and you would differentiate "null" from "undefined"?

On Friday, 17 January 2014 at 05:30:45 UTC, H. S. Teoh wrote:
> Now, if we modify this sentinel to instead record the location of the
> code that first initialized it (via __FILE__ and __LINE__ default
> parameters perhaps), then we can set it up to print out this information
> at a convenient juncture, so that the source of the uninitialized
> reference can be determined. *Then* perhaps it will be a start of a

Which is easy to do (in theory). Page zero is over a thousand unique adresses. All you have to do is to convert null-tests to a range test. E.g. (addr&MASK)==0

On 2014-01-19 20:07:40 +0000, Timon Gehr <timon.gehr@gmx.ch> said:

> On 01/19/2014 01:03 PM, Michel Fortin wrote:
>> Actually, 'A?' would implicitly convert to 'A' where the compiler can
>> prove control flow prevents its value from being null.
> 
> I think the type should be upgraded. i.e.:
> 
>> So you can
>> dereference it in a branch that checked for null:
>> 
>>      class A { int i; void foo(); }
>>      void bar(A a); // non-nullable parameter
>> 
>>      void test(A? a, A? a2)
>>      {
>>          a.i++; // error, 'a' might be null
>>          a.foo(); // error, 'a' might be null
>>          bar(a); // error, 'a' might be null
>> 
>>          if (a)
>>          {
>                 static assert(is(typeof(a)==A));
>>              a.i++; // valid [...]
>>              a.foo(); // valid [...]
>>              bar(a); // valid [...]
>>          }
>>      }

That's one way to do it. Note that this means you can't assign null to 'a' inside the 'if' branch. But I wouldn't worry too much about that. I think it'd make a good first implementation.

What I expect from a not-null feature is that it starts by being over-restrictive and with time, as the control flow analysis evolves, unnecessary restrictions would be lifted. That's similar to how CTFE and purity became what they are today.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On Monday, 20 January 2014 at 00:44:21 UTC, Michel Fortin wrote:
> On 2014-01-19 20:07:40 +0000, Timon Gehr <timon.gehr@gmx.ch> said:
>
>> On 01/19/2014 01:03 PM, Michel Fortin wrote:
>>> Actually, 'A?' would implicitly convert to 'A' where the compiler can
>>> prove control flow prevents its value from being null.
>> 
>> I think the type should be upgraded. i.e.:
>> 
>>> So you can
>>> dereference it in a branch that checked for null:
>>> 
>>>     class A { int i; void foo(); }
>>>     void bar(A a); // non-nullable parameter
>>> 
>>>     void test(A? a, A? a2)
>>>     {
>>>         a.i++; // error, 'a' might be null
>>>         a.foo(); // error, 'a' might be null
>>>         bar(a); // error, 'a' might be null
>>> 
>>>         if (a)
>>>         {
>>                static assert(is(typeof(a)==A));
>>>             a.i++; // valid [...]
>>>             a.foo(); // valid [...]
>>>             bar(a); // valid [...]
>>>         }
>>>     }
>
> That's one way to do it. Note that this means you can't assign null to 'a' inside the 'if' branch. But I wouldn't worry too much about that. I think it'd make a good first implementation.
>
> What I expect from a not-null feature is that it starts by being over-restrictive and with time, as the control flow analysis evolves, unnecessary restrictions would be lifted. That's similar to how CTFE and purity became what they are today.

I don't see the point of intruducing a new syntax for nullable, when D typesystem is already powerful enough to provide it as lib.

On Sun, Jan 19, 2014 at 09:41:20PM +0000, digitalmars-d-bounces@puremagic.com wrote:
> On Friday, 17 January 2014 at 05:30:45 UTC, H. S. Teoh wrote:
> >Now, if we modify this sentinel to instead record the location of the code that first initialized it (via __FILE__ and __LINE__ default parameters perhaps), then we can set it up to print out this information at a convenient juncture, so that the source of the uninitialized reference can be determined. *Then* perhaps it will be a start of a
> 
> Which is easy to do (in theory). Page zero is over a thousand unique
> adresses. All you have to do is to convert null-tests to a range
> test. E.g. (addr&MASK)==0

It's not that simple. In assembly, usually the pointer value is just a base address, you add the field offset on top of that before you even attempt to load anything from memory. So you can't use "different nulls" to represent different source locations that easily.


T

-- 
There's light at the end of the tunnel. It's the oncoming train.

On Monday, 20 January 2014 at 01:22:34 UTC, H. S. Teoh wrote:
>> adresses. All you have to do is to convert null-tests to a range
>> test. E.g. (addr&MASK)==0
>
> It's not that simple. In assembly, usually the pointer value is just a
> base address, you add the field offset on top of that before you even
> attempt to load anything from memory. So you can't use "different nulls"
> to represent different source locations that easily.

Why not? You don't trap address zero, the MMU traps pages of 4K size on x86.

But when you have an explicit nullptr test you will have to mask it before testing the zero-flag in the control register.