On Tue, 28 May 2013 05:35:22 +0200, deadalnix <[email protected]> wrote:
On Monday, 27 May 2013 at 21:55:00 UTC, Simen Kjaeraas wrote:
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?
Same problem exists with any type with @disable this.
Indeed. But not with @disable this() itself. If you don't like the way
it's implemented - roll your own, it's in the library.
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 */ })?
if reference are non nullables, this example don't make any sense.
So you're arguing that all nullables should be banned? How else can you
be so sure my foo can't be 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.
It is. Having everybody considering it isn't is probably why you'll find
so much holes in NonNullable.
It isn't. See above.
--
Simen
