Another outside POV..
On Wed, 29 May 2013 10:20:39 +0100, deadalnix <[email protected]> wrote:
On Wednesday, 29 May 2013 at 07:50:39 UTC, Kenji Hara wrote:
Currently I recognize that it is necessary to fix compiler bugs around
@disable this(); at least.
@deadalnix, it seems to me that you argue that @disable this(); is
insufficient or useless to implement NotNull!T. If so, what is
necessary to
do it? What is impossible thing by NotNullT?
No I'm nto saying that this is impossible, I'm saying that @disable
this() and non nullable pointer are the exact same feature.
To implement both, the compiler have to track initialization of the
value and yell at you if it isn't done, or if the value read before
being initialized.
I don't understand why this is so hard to understand.
It's not. Everyone understands this point, it's not the point of
contention.
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?
IMO, this then renders any specific not-null language feature
unnecessary. And, allows a library type to do the job.
Now, as D assume all over the place that everything can be initialized
by default, so making @disable this work require a larger design change
than simply pluging holes. It means that as of now, some entities can't
be initialized by default.
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?
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
