> If you want to play around with that, that's fine, but the language is not
> going to change, so please to post code which uses your changes. If you start
> making changes to the compiler, you can't really expect other people to help
> you figure out what's wrong with your code - especially since your changes
> could be causing your problems (though I think that that's unlikely in this
> particular case).

Yes, sorry for that, it wasn't my intetion, i forgot (it was my own test case for that compiler change)

> Okay. I missed that, but that's probably your problem then. The definitions of
> of Foo and NotNull are recursive, which I don't believe is legal.

You mean it's illegal that i have two "alias this" in both, the Fo class and the NotNull struct?
I hope that this case would be never illegal.
And as i understood kenjii, he works on a fix that solves the problem with the infinity loop.

> It's almost certainly what's causing the compiler to eat up tons of CPU and memory and
> then die. In fact, if I fix the issue with Ptr returning a pointer to a class,
> and remove Foo's alias this and its associated function, the code compiles
> just fine with
>
>  test_normal_foo(f2);
>
> uncommented. Which in and of itself is disturbing, since there's no implicit
> conversion anymore. So, I think that there's definitely a bug there beyond the
> weird error that you're seeing.

But this was my intention: that Foo is implicit convertable to NotNull!(Foo) and that NotNull!(Foo) is implicit convertable to Foo.


> However, the compiler doesn't even do that right now, so I don't know why
> you're getting the complaint about null dereferencing that you're getting.

That's too bad.

> Actually, it looks like it had been a few days since I updated my compiler.
> Now, if all I do is change Ptr to
>
>  @property
>  auto Ptr() {
>  static if (isPointer!(T) || is(T == class)) {
>  return this._val;
>  } else {
>  return &this._val;
>  }
>  }

I get only a msg, that it doesn't compile.
But this works fine:
	static if (is(T _unused : U*, U)) {
		@property
		inout(T) Ptr() inout {
			return this._val;
		}
	} else {
		@property
		inout(T*) Ptr() inout {
			return &this._val;
		}
	}

> then I get a segfault instead of dmd eating up CPU and memory, which is an
> improvement but not really acceptable, since the compiler isn't supposed to
> segfault. I don't know what the state of your bug report is, so I don't know
> if it's considered fixed or not.
>
> - Jonathan M Davis

Here it is: http://forum.dlang.org/thread/bug-7980-3@http.d.puremagic.com%2Fissues%2F

On Monday, July 02, 2012 12:45:16 Ali Çehreli wrote:
> On 07/02/2012 11:36 AM, Jonathan M Davis wrote:
> > 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.
> 
> Then why is the documentation so misleading:
> 
> -w enable warnings
> 
> -wi enable informational warnings (i.e. compilation still proceeds normally)
> 
> http://dlang.org/dmd-linux.html
> 
> Me not know English good, but -wi sounds very much different from -w. :-T
> 
> Further, both -w and -wi link to the following page, which does not mention -wi at all:
> 
> http://dlang.org/warnings.html
> 
> Sorry for whining... :(

That's what comes of -wi being tacked on later, I suppose. Clearly that needs to be fixed. If it were any other compiler -wi would be the default behavior, but Walter wrote it, so Nick had to beg until Walter suprisingly relented and added -wi. Personally, I just always compile with -w and that -w was the default, but whatever. The documentation needs to be fixed in either case.

- Jonathan M Davis

At last a further Stack overflow, maybe you could explain me why.

It comes if i try to outsource the redundant code with a mixin template like this:

[code]
mixin template TRef(T : Object) {
private:
	NotNull!(T) _nn;

public:
	@property
	NotNull!(T) GetNN() {
		return this._nn;
	}

	alias GetNN this;
}

class Foo {
/*
private:
	NotNull!(Foo) _nnf;
*/
public:
	mixin TRef!(Foo);

	this() {
		this._nnf = NotNull!(Foo)(this);
	}

	void Identicate() const {
		writeln(Foo.stringof);
	}
/*
	@property
	NotNull!(Foo) GetNN() {
		return this._nnf;
	}

	alias GetNN this;
*/
}
[/code]

Without the mixin it compiles fine.
I tried comment out "alias this" in the mixin template and write it into the class, but it seems that it isn't relevant.