Error: null dereference in function _Dmain

[Namespace]

> Well, I'm getting
>
> q.d(111): Error: no identifier for declarator t
> q.d(111): Error: found 'in' when expecting ';'
>
> due to your erroneous use of in a foreach loop instead of ;,

Sorry, that comes of my little compiler hack, as you can see here:
http://forum.dlang.org/thread/rbltrlxsogrfxjzqfpxe@forum.dlang.org?page=3
and here, if you like to read my mother language ;)
http://blog.rswhite.de/archives/791

> but with that
> fixed I see
>
> Error: null dereference in function _Dmain
> q.d(103): Error: null dereference in function _Dmain
>
> which refers to
>
> test_not_null_foo(f1);
>
> which is a very weird error. test_not_null_foo takes a 
> NotNull!Foo, not a Foo,
> and f1 is a Foo, and you haven't defined an implicit conversion 
> from Foo to
> NotNull!Foo, so it should give an error about NotNull!Foo not 
> being Foo.

I have, as you can see here:

[code]
	@property
	NotNull!(Foo) GetNN() {
		return this._nnf;
	}

	alias GetNN this;
[/code]

line 75 in my DPaste code.

> If you compile without -O, this code compiles without error, 
> which is wrong. And
> if you compile with -O, you get the weird null dereference 
> error.
I like it, this error detect null referenced as i wanted, that 
great!


> By the way, you're handling classes incorrectly in your NotNull 
> struct.
> isPointer!T is false for classes, so your Ptr function is 
> returning a pointer
> to a class rather than a class. You need is(T == class) if you 
> want to test
> whether T is a class. You seem to have created isObject to try 
> and solve that
> problem, but isObject is going to give you funny results if T 
> isn't a class
> but does have an alias this which converts to one.

Thanks! I will fix it.

> However, if you fix it so that Ptr returns an inout(T) for 
> classes like it
> should, dmd seems to hit 100% CPU and grow in memory until the 
> OS kills it.
> So, you're definitely hitting a bug with alias this here, but I 
> don't know if
> that's a third bug or something else. I recall there being a 
> recent bug report
> about the compiler running out of memory in a similar 
> situation, but I'd have
> to go digging for it to be sure.

That's a bug i posted a while ago and i thougth that kenjii fix 
it in 2.060, or not?
The compiler create an infinite loop and convert from Foo to 
NotNull!(Foo) and back and so on.
If you create _one_ instance and returns them as pointer (or cast 
them as pointer, as you can se at my opCast method) the compiler 
breaks the conversion immediately. A little hack i detected and 
help me to realize the NotNull struct as i want. :)

> By the way, it's pointless to compile with both -w and -wi. -wi 
> makes it so
> that warnings are displayed without stopping compilation. -w 
> makes it so that
> warnings are displayed and treated as errors (so they stop 
> compilation). Pick
> one or the other. I don't know which the compiler picks if you 
> give it both,
> but it's going to have to pick one or the other, and it may not 
> pick the one
> that you want.
>
> - Jonathan M Davis

Thansk again, i will fix it too.