[Issue 4571] New: Non-null class references/pointers

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=4571

           Summary: Non-null class references/pointers
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody at puremagic.com
        ReportedBy: bearophile_hugs at eml.cc


--- Comment #0 from bearophile_hugs at eml.cc 2010-08-02 16:27:19 PDT ---
This is a starting point for an enhancement request about a type modifier to
specify that a class reference or pointer can't be null.

This is not an enhancement request about "nullable values" (values wrapped in a
struct that contains a boolean that is true if the value is "null").

This enhancement request assumes that on default both class references and
pointers are nullable (because today defaulting to non-null class references is
probably an impossible change in D).


A possible D syntax to denote a non-null reference or pointer is to use a @
suffix (better looking alternatives are possible):

class T {}
T nullable_reference;
T@ nonnullable_reference = new T@();

struct S {}
S nullable_pointer;
S@ nonnullable_pointer = new S@();


A possible alternative is to use the - (or +) suffix:

class T {}
T nullable_reference;
T- nonnullable_reference = new T-();

struct S {}
S nullable_pointer;
S- nonnullable_pointer = new S-();


A possible problem with non-null class references can be seen with this D
program that uses the trailing @ syntax:

class Foo {}

class A {
    Foo@ name;
    this(Foo@ s) {
        this.name = s;
        this.m();
    }

    void m() { /*...*/ }
}

class B : A {
    Foo@ path;
    this(Foo@ p, Foo@ s) {
        super(s);
        this.path = p;
    }

    override void m() {
        // here this.path is null despite it's a non-null
        assert(this.path !is null);
    }
}

void main() {
    new B(new Foo, new Foo);
}


I have adapted that example from this paper, it discusses about partially
uninitialized objects too:
http://research.microsoft.com/pubs/67461/non-null.pdf

A comment about that program from the paper:

>The problem with the code is that during the base call to A's constructor, the virtual method B.m may be invoked. At this time, field path of the object under construction has not yet been initialized. Thus, accesses of this.path in method B.m may yield a possibly-null value, even though the field has been declared as being non-null.<

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------