On Sunday, 22 April 2012 at 16:59:05 UTC, Jesse Phillips wrote:
As such checkNotNull shoud be more than throwing an exception.
I have tried this, but it should get some constraints. Also
wouldn't the new lambda syntax look nice with null here: null
=> unsafe(a)?
Yeah, I like this idea, though a lot of what I do
is more like
if(x !is null) use(x);
hmmmm, the default could be to simply do nothing on
the other side. I think we can work with the lambda idea.
The other null related things on my mind are:
1) if we could make new return NotNull!T. I guess
we could offer an alternative:
NotNull!T create(T, Args...)(Args) {
return assumeNotNull(new T(Args));
}
Though "new" is so well entrenched that I don't think
it is going anywhere, and having a language construct
depend on a library structure is pretty meh.
So meh.
2) When doing chained calls, have it simply ignore the
rest when it hits null.
suppose:
if(a) if(auto b = a.something) b.more();
I guess some languages would call that
a?.something?.more();
but I wonder if we can do it in a library somehow.
ifNotNull(a).something.more();
Suppose it returns a wrapper of a that has an opDispatch
or something that includes the if check, and wraps
the rest of the return values.
I'm pretty sure we can do that!
