On Wed, 29 May 2013 17:27:41 +0100, deadalnix <deadal...@gmail.com> wrote:
On Wednesday, 29 May 2013 at 15:02:53 UTC, Regan Heath wrote:
Which is what exactly? That 2 features not-null and @disable this()
are the same thing? They're not, one is a subset of the other. That
they require the same compiler functionality, we all agree, but that's
not really important or relevant. What is relevant is whether NotNull
can be implemented using @disable this, and you've agreed that it can.
In the first place, I was simply answering people that were claiming
that non null pointer require more work compiler wise than @disable
this(). For some reasons, this was repeated and put out of context.
Ok. I think the confusion around this statement is that it can be
interpreted to mean, from the current state of the compiler with @disable
this() adding not-null requires no more work. Whereas, you simply meant
that from a clean slate both features require the same work. The issue
here is that your point is irrelevant, because we're not starting from a
clean slate.
I also don't think the statement is true (see below).
The point is made to debunk the false argument that non null is extra
work. Nothing more, nothing less.
From the current state of D/DMD not-null /is/ extra work, as Jesse posted:
* Choose syntax
* Integrate with other language features (e.g. new)
* Decided on how to obtain a non-nullable from a nullable (and other
choices also made by implementing NotNullable!
From a clean slate not-null and @disable this() both require items #1 and
#2 above, but @disable this() doesn't require item #3.
So either way not-null still requires extra work.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
