On 05/29/2013 05:07 AM, Jesse Phillips wrote:
Outsider summary:
* Implementing @disable provides the groundwork for a working
non-nullable type
* Non-nullable types cannot make a working @disable
Adding non-nullable to a library
* Implement NotNullable!T
Adding non-nullable to the language
* 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!T)
From the arguments present, I side with Simen that implementing the new
type in the language would not be the same as building the library type.
@disable only provides the initialization tracking required to have a
non-nullable type. But the type still must be implemented and if added
to the language it would need to be integrated with other elements of
the language, while a library type uses existing integration points.
BTW, @disable was added to build a non-nullable type. So it should be
included in the current effort to get non-nullable in D; though its
added benefits for other applications is nice.
What many appear to be missing is that the most important part of any
such design is that there should be no such thing as a null dereference.
In this context the term non-null seems funny, it is somewhat like
calling a car engine a non-coal engine. "Non-null" makes the most sense:
If I say the type of x is 'pointer to a T', then it is natural to expect
to find a T somewhere.
