On 5/18/2013 5:04 PM, deadalnix wrote:
On Saturday, 18 May 2013 at 20:59:41 UTC, Simen Kjaeraas wrote:
@disable this is awesome, really. And you're right that it's even better than
simple non-nullable pointers. Lastly, it's great that it's getting fixes. It's
been one of my favorite non-working features. :p
The subject here is default constructor, not really nullable pointer. @disable
this() cost as much as default constructor, but provide less. I don't see any
objective reason to limit default constructor as disabled but not enabled.
I'd even argue that it actually cost more as it introduce yet another special
case.
this() { assert(0); }
makes for a runtime check, not a compile time one. Compile time checks are more
efficient in both programmer time and run time.
Note that C++11 8.4.3 has @disable as well, in the form:
S() = delete;
In a way, I fear that we'll end up like C++, with bare pointers/references
being considered experts-only and 'special use', and everyone will use smart
pointers instead.
No what will happen it that we will have null all over the place with missing
check, and no stack trace when it fails, because NullPointerError have been
decided to be bad.
regular references/pointer are used way more than in C++ because you don't need
to do the manual memory management that goes with it in D.
We will have more bugs and slower programs due to null checks all over the
place, and unexpressed assumption about what can be null and what cannot.
With NotNull, the runtime check only happens upon assignment and initialization
from a pointer type. Dereferencing, copying, etc., of NotNull entails zero
runtime overhead and no checks.