Struct with default ctor (Was: [dmd-beta] dmd 2.064 beta take 2)

[Simen Kjaeraas]

On Sun, 19 May 2013 21:02:11 +0200, Idan Arye <GenericNPC at gmail.com> wrote:

> I don't see how Option and Maybe would have helped your bug. The problem  
> was that somewhere in the code the reference was perceived as null while  
> in fact it wasn't

What does that even mean?


> - so now it will be perceived as `None`, and you will have the same  
> problem.

Except that now the code would be forced to handle the None case. In a way,
having nullable by default is like having a stringly typed system:

function foo( s ) {
    return (s + 4) * 2; // Works great when s == "16", falls dead on its
                        // back when s == "goobers".
}

function bar( int i ) {
     return (i + 4) * 2;
}


These functions look very different. That's because they are. One of them
only takes valid parameters, the other takes any old garbage and barfs
when the wrong garbage is given to it.

Of course, if you have a string, and you want to call bar, you need to
convert the string to an int. So you end up with this:

function baz( string s ) {
     return s.parseInt(
         i => bar(i),
         { alert("error"); });
}

Notice how the parseInt function takes two delegates? One of these
(the first) is only called when the string is valid. The other is only
called if the string is invalid. That way, we can be sure that the
failure case is handled.

Exactly the same would be the case for non-nullable pointers - if you
want to convert a nullable pointer to non-nullable, you *have* to
handle the failure case. No two ways about it.

Now, the same example with class references:

int foo(A a) {
    return a.qux(); // Works great when a == new A(), falls dead on its
                    // back when a == null.
}

int bar(NonNull!A a) {
    return a.qux();
}

See how one of these does not blow up in your face (unless you do
something stupid like create a special Nil value that will do exactly
that)? Now, for baz:

int baz(A a) {
     return a.match(
       (NonNull!A a) => bar(a),
       (None) => -1
       );
}


>> And this is the exact problem with nullable by default : plenty of  
>> stuff ends up be null is some weird situation that almost never occurs  
>> when they are assumed not to be and the program crashes.  
>> NullPointerException now return 4 millions result on google, which is  
>> probably around once per java developers.
>
> This is not a problem with "nullable by default" - it is a problem with  
> implicit default values. null(or Nil, or None) are the only sane default  
> values for reference types - I think you would agree that having to  
> construct a new blank object as default value for every reference  
> variable would be far worse than null...

If you absolutely cannot initialize the pointer to something sensible,
then use a nullable pointer. But if non-nullable pointers are not
available, or are harder to use than nullable pointer, then people will
use nullable pointers even where non-nullable would have been a much
more fitting choice.



> It does not solve the bug - it is something you HAVE to do given the  
> assumptions. If the reference is not nullable, and you can't set it to  
> it's real value until later in the code, then you have to initialize it  
> to some temporary value.

I don't know enough about the bug to say such things for sure, but I will
say this: If deadalnix solved the bug, he is likely in a much better
position to say anything about what would solve the problem than the rest
of us.

-- 
Simen