On Sunday, 2 February 2014 at 13:18:19 UTC, Nick Treleaven wrote:
I read your recent post about this, it was interesting. But I
don't think you can disallow this:
auto cn = checkNull(cast(C)null);
NotNull!C nn = cn;
obj2 is then null, when it shouldn't be allowed.
It wouldn't be null - it would be a runtime assertion failure
(except in release mode, when it would indeed be null). I think
that's OK.
Two reasons this is an improvement anyway:
1) The error message of "cannot implicitly convert cn of type C
to nn of type NotNull!C" made you realize there's a potential
problem here and attempt a fix.
That's why checkNull is there in the first place - it made you
consider the problem. Your fix isn't really right, but at least
now it should be obvious why.
2) The assertion failure happens right there at the assignment
point (the assert is in NotNull's constructor) instead of at the
use point. So when it fails at runtime, you don't have to work
backwards to figure out where null was introduced, it points you
straight at it and it won't be too hard to see that cn wasn't
properly checked.
Maybe not perfect, but I really think it is good enough and an
improvement.... if people actually use NotNull!T in their
functions and structures in the first place.
