Proposal : allocations made easier with non nullable types.

[Daniel Keep]

Alex Burton wrote:
> I think it makes no sense to have nullable pointers in a high level language like D.

Oh, and how do you intend to make linked lists?  Or trees?  Or any
non-trivial data structure?

Saying they have no place in a language is just silly; the question
should be whether they should be the default or not (I would contend
that they shouldn't be.)

> In D :
> 
> X x = new X;
> This is a bit redundant, if we take away the ability to write X x; to mean X x = 0; then we can have X x; mean X x = new X;
> If the class has a ctor then we can write X x(32); instead of X x = new X(32);

Can I just say that I *LOATHE* this syntax?  It's one thing I always
despised about C++; it simply makes NO sense whatsoever.  It looks like
the bastard offspring of a function declaration and a function call.

The first *is* redundant, but then I wouldn't state X twice, I'd use
"auto" (because types are almost never a single letter anyway.)  Add to
that that the existing syntax is much more intuitive; it even reads like
a sentence.

> Only when the types of the pointer and class are different do we need to write X x = new Y;
> We can do this syntactically in D because classes cannot be instantiated on the stack (unless scope is used, which I have found a bit pointless, as members are not scope so no deterministic dtor)

I made a proposal quite some time ago detailing how we could have not
only scope members of classes, but even scope RETURN values, but I think
it got maybe one reply... :P

Given that one of D's tenets is to make it simpler to write
deterministic, bullet-proof code, the complete lack of deterministic
destruction of classes has always felt like a huge hole in the language.

> This makes the code much less verbose and allows code to change from X being a struct to X being a class without having to go around and change all the X x; to X = new X;

Something interesting about C# that I'd forgotten until recently...

> Vector2 v = new Vector2();

What is Vector2?


...


It's a struct.  In C#, there's no syntactic difference between
instantiating a class and initialising a struct.  Most C# code doesn't
have pointers, so this isn't an issue.

(Note that I don't have any idea how you would heap-allocate a value
type in C#; I'm not even sure if it's possible...)

> As I said in the nullable types thread:
> Passing 0 or 0x012345A or anything else that is not a pointer to an instance of X to a variable declared as X x is the same as mixing in a bicycle when a recipe asks for a cup of olive oil.

Passing garbage to a function doesn't have any bearing on the
non-nullable discussion.  If you're casting random integers to pointers
and passing them to functions, you reap what you sow. :)

That said, passing null is more like omitting an ingredient.  Which is
unfortunate if you're making soup and the ingredient is "water."

> There are much better, and less error prone ways to write code in a high level language than allowing null pointers.
> 
> Alex

While I'm a strong believer in non-nullable types, I don't think null
pointers are evil.  They're a tool like anything else; problems only
arise when you misue them.

I believe they're the wrong default choice, because they don't come up
in normal code, but you've got to fall over yourself to make sure they
don't become an issue.

Let me chip in a practical example that happened just yesterday.

I'm throwing together a game prototype.  Since this is C#, I don't have
contracts, so I'm making judicious use of Debug.Assert calls to ensure
that object references are non-null.

And surprise, surprise, my program crashes with null dereference errors.
 I walk the stack trace back, only to discover that the null got stored
at some point.  So the program doesn't even crash when the problem
occurs (storing a null reference in a field that shouldn't have one) it
occurs later in the execution when I'm no longer able to easily
determine what went wrong.

Eventually, I tracked it down to one of the few places in the code that
I forgot to assert the reference was non-null.  It was null because
Microsoft didn't bother to document that a particular "magic object"
doesn't exist until a certain point.

  -- Daniel