Proposal : allocations made easier with non nullable types.

[Nick Sabalausky]

"Daniel Keep" <daniel.keep.lists at gmail.com> wrote in message 
news:gmpd71$8uj$1 at digitalmars.com...
> 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?
>

Null Object Pattern:
--------------
class LinkedListNode(T)
{
    LinkedListNode!(T) next;

    private static LinkedListNode!(T) _end;
    static LinkedListNode!(T) end() {
        return _end;
    }
    static this() {
         _end = new LinkedListNode!(T);
    }
}
--------------

However, I admit this is little more than re-inventing null. But it's at 
least possible.

> 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.)
>

Agreed.

>> 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.
>

Just a thought: Would you hate this less:
X(32) x;

>> 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.
>

I don't suppose you have a link or the subject line of that handy?

>> 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."
>

I have to say, I'm loving these analogies :-)

> 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.
>

That's pretty much my opinion on the matter as well. Null Object Pattern is 
a usable alternative to nullables, and even more powerful (the "null" is 
capable of functions, data and polymorphism), but in the cases when you 
don't need that extra power, a non-default nullable is just less work and 
isn't really any less safe.

> 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.
>

C#/.NET does seem to have some odd quirks like that. A few weeks ago, I was 
pulling my hair out figuring out a particular bug, and stepping through in 
the debugger only perplexed me more. Turned out there was an object with a 
property I was setting, but the new value was somehow "queued" and didn't 
actually take until later on. The docs hadn't mentioned that particular 
behavior.