On Wednesday, 29 May 2013 at 12:19:54 UTC, Regan Heath wrote:
I started discussing this because people where claiming that
non null makes the compiler more complex to implement, which
is completely false.
That's not the argument being made by Simen. The argument is
that @disable this() is a feature which allows a set of
features which include but is not limited to not-null, and is
therefore a superior feature to have.
Do you agree?
I do agree that @disable this is useful. *BUT* the argument made
is based on the untold assumption that both are mutually
exclusive, which is not true.
IMO, this then renders any specific not-null language feature
unnecessary. And, allows a library type to do the job.
Most people agree that you'll find 2 useful behavior : non
nullable and nullable with obligation of handling the null case.
The default behavior right now provide none of thoses. It behave
just as if it were non nullable, and simply crash when they
happen to be null.
This behavior isn't useful. You'll find no argument except
historical reason (which is a very valid argument BTW) to keep
that. Everything else is backward rationalization.
Assuming, as you say, that @disable this() and not-null require
the same compiler work, these holes that need plugging would
need plugging in either case, right?
Yes.
