On Mon, 27 May 2013 20:00:30 +0200, deadalnix <[email protected]> wrote:
On Monday, 27 May 2013 at 17:41:37 UTC, Walter Bright wrote:
On 5/27/2013 2:17 AM, deadalnix wrote:
But the argument about compiler feature don't stand, as nonnull
pointer and
@disable this require the exact same processing in the compiler.
Yes, it does stand, as there is a lot of other types that can benefit
from @disable this. If notnull is a core feature, then only that works.
I never said that they are mutually exclusive. All the contrary, I say
they are the same thing. And that if you have one, you have no reason
not the have the other.
Ah, like that. Your posts could be read as 'non-nullable pointers give
the *exact* same benefits as does @disable this()', which is simply untrue.
Now, if we wanted to add compiler support for non-nullable references, many
more things would need to be decided - how do they look? Do they assert
non-nullness upon initialization/assignment, or are external checks
required?
Does new Foo() return a non-nullable reference? Must we also add scoped
non-nullness guarantees (if(foo != null) { /* foo is now implicitly
convertible to non-nullable */ })?
So, no. The stuff required to add @disable this() to the language is not
the
same that is required for non-nullable references. It's certainly an
important
part of it, but there's still more left, and it's going to make the
language
harder to implement. Adding a feature that lets non-nullable references be
added in a library is much better.
--
Simen
