On Sunday, 22 April 2012 at 10:58:10 UTC, Namespace wrote:
If i got you right on git, you wouldn't allow something like
this:
NotNull!(Foo) f = new Foo(); and instead you want that
everybody writes
NotNull!(Foo) f = assumeNotNull(new Foo);
Is that correct?
No, I think that's too annoying, though I also think
it is more correct.
But my plan is to allow NotNull!Foo f = new Foo().
(This is a constructor, so removing opAssign doesn't change
this.)
there because of the explicit conversion constraint from Foo
into NotNull!(Foo) which i described in my post above.
That explicit conversion is one of the features of the
type - it means the compiler will remind you when you
missed something.
There's really little benefit to checking at a function
automatically. If you need that, you can always assert for
it in an in{} contract.
Or just use it and let the debugger take care of the rest.
I think a debug build on Windows even gives a stack trace
on null deref, but I'm not sure.
The big benefit with not null types is making sure you don't
store a null somewhere, since that's a lot harder to track
down.
