www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4571] New: Non-null class references/pointers

reply d-bugmail puremagic.com writes:
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 puremagic.com
        ReportedBy: bearophile_hugs eml.cc


--- Comment #0 from bearophile_hugs 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: -------
Aug 02 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4571



--- Comment #1 from bearophile_hugs eml.cc 2010-08-26 16:41:58 PDT ---
This is just half of a solution. Beside introducing nonnull
pointers/references, and a handy syntax to denote them, to have a null-safe
language you also need to require explicit tests every time a nullable
pointers/references is about to be dereferenced, and then after this test in
the else branch the reference type "becomes" a non-nullable one.

This is an application of the idea of "TypeState", used by the Mozilla Rust
language. The type doesn't actually change, it's just its state that change.

More on the concept of TypeState (at the moment it is not present in
Wikipedia):
http://www.google.com/search?q=typestate

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 26 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4571



--- Comment #2 from bearophile_hugs eml.cc 2010-08-26 17:27:34 PDT ---
An example implementation of TypeState for Java:
http://www.warski.org/blog/?cat=9
http://www.warski.org/typestate.html

The original paper about typestates, Typestate: A Programming Language Concept
for Enhancing Software Reliability", by Robert E. Strom and Shaula Yemini,
1986:
http://www.cs.cmu.edu/~aldrich/papers/classic/tse12-typestate.pdf

A version for dotnet, Typestates for Objects", by R. DeLine and M. Fähnrich:
http://www.cs.cmu.edu/~aldrich/courses/819/slides/typestates.ppt
http://research.microsoft.com/apps/pubs/default.aspx?id=67458
The software:
http://research.microsoft.com/en-us/projects/fugue/
(But it says Fugue is no longer supported as a tool. However, check out our
related project called CodeContracts.")

More on the topic:
http://www.cs.cmu.edu/~aldrich/papers/onward2009-state.pdf

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 26 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4571



--- Comment #3 from bearophile_hugs eml.cc 2010-10-21 17:52:56 PDT ---
Another older partial implementation of typestates from Microsoft, in the Vault
language:

http://web.archive.org/web/20060706065107/research.microsoft.com/vault/learn/typing/typing.htm

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 21 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4571



--- Comment #4 from bearophile_hugs eml.cc 2010-11-04 13:41:10 PDT ---
This good document explains very the very well though-out design and
implementation of nonnullable reference types in Spec#:
http://research.microsoft.com/en-us/um/people/leino/papers/krml189.pdf

The article shows how to manage the nullable pointers/references with the help
of if statements, assertions and casts too.

It shows the need for annotations to denote both nullable and nonnullable
version of a type. In D the nullable version may use ? and the nonnullable
version may use  . So if T is a reference type parameter, then T is type
parameter itself (that might be a nullable or not type), T? is the nullable
version of T, and T  is for the nonnullable version of T.

The document also suggests a shorter syntax to cast a variable to a nullable or
not nullable versione of its type:
cast( )someRef
cast(?)someRef

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 04 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4571



--- Comment #5 from bearophile_hugs eml.cc 2011-12-12 05:12:30 PST ---
See also:
http://eclipseandjazz.blogspot.com/2011/12/inter-procedural-null-analysis-using.html

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 12 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4571



--- Comment #6 from bearophile_hugs eml.cc 2012-10-01 14:26:20 PDT ---
A small program that shows three important things std.typecons.Nullable isn't
able to do:


import std.stdio, std.algorithm, std.typecons;

alias Nullable!(int, -1) Position;

void foo(int[] a, Position pos) /*nothrow*/ { // allow this to be nothrow
    if (pos.isNull) {
        return;
    } else {
        a[pos] = 10; // perform no nullness test here, optimization
    }
}

void bar(int[] a, Position pos) {
    a[pos] = 10; // compile-time error here?
}

void main() {
    auto data = [1, 2, 3, 4, 5];
    auto p = Position(countUntil(data, 7));
    foo(data, p);
    writeln(data);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 01 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4571


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


--- Comment #7 from bearophile_hugs eml.cc 2013-04-06 06:37:46 PDT ---
Closed down by request by Andrei:

http://forum.dlang.org/post/kjp56a$e1s$1 digitalmars.com

Not-nullable reference types have gained appreciation in almost every type-rich
recently designed languages, as F#, Scala, Rust, and few Java-Like languages
running on the JavaVM. I think all type-rich languages that will be designed in
future will have nonnullable typing.

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