[article] Language Design Deal Breakers

[Timon Gehr]

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.