On Sun, 19 May 2013 02:04:09 +0200, deadalnix <deadal...@gmail.com> 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.
Define cost and provide here. Adding default constructors to the language
does not provide the same benefit as does @disable this(), and definitely
has costs of its own.
Note: I'm not arguing against adding default constructors, I'm arguing
against what I see as flawed or at least limited, logic.
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.
Or... possibly, the current holes in @disable are fixed, and NonNull!T
becomes the default, because we tell people to always use them, rather
than flail our arms and behave like idiots. ("regular pointers are
broken, use NonNull!T" is a pretty good argument if it's true)
--
Simen