Proposal : allocations made easier with non nullable types.

[Daniel Keep]

Nick Sabalausky wrote:
> "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.

And don't forget that in doing this, you've lost the benefit of
dereferencing a null crashing the program: if you accidentally access
the _end member, you won't notice unless you explicitly check for it.

>> [snip]
>>> In D :
>>>
>>> ... 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.
>>
>> ...
> 
> Just a thought: Would you hate this less:
> X(32) x;

That's just as bad; it looks like a parameterised type where you forgot
the '!'.

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

Took me a while to find it, even knowing what it was about.  Ended up
having to manually go through the digitalmars.com archives. :P

http://www.digitalmars.com/d/archives/digitalmars/D/38329.html

It's probably somewhat anachronistic now.  For anyone who isn't aware,
back in the old days, 'scope' was 'auto' whilst 'auto' was 'auto.'  It
sort of did two things and was a bit confusing.  Just replace 'auto'
with 'scope' and you should be fine.  :P

Also, back then auto didn't stack-allocate.  If I may digress to the
land of make-believe for a moment: if this proposal was implemented, you
could get around the whole "stack allocation" thing like this:

{
    scope X foo()
    {
        return new X;
    }

    scope X x = foo();
}

Which could become this:

{
    void foo(ubyte[] storage, inout X ptr)
    {
        static if( X.sizeofinstance > storage.length )
        {
            ptr = new X;
        }
        else
        {
            storage[0..X.sizeofinstance] = cast(ubyte[])(new X);
        }
    }

    ubyte[X.sizeofinstance] x_storage;
    scope X x = x_storage.ptr;
    foo(x_storage, x);
}

The caller allocates enough space for an instance of X and passes both
the storage and the actual reference variable.  The caller can then
either store the instance in that array, or make the reference point to
somewhere else.

Just a thought. :P

</digression>

>> [snip]
>> 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.

I'd argue it's more safe because it'll crash your program faster. :D

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

Microsoft just seems to be really bad at documentation.  They go to all
that effort of creating a tremendous amount of documentation, but don't
succeed in actually saying anything.

My favourites are the innumerable classes in .NET or XNA that document
every single member function and property... but fail to state what any
of them ACTUALLY DO.  Or what the arguments are for.  Or what the valid
values are.  Or under what circumstances it's usable.  Or how to even
create the bloody things.

  -- Daniel