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/[email protected]%2Fissues%2F
