[article] Language Design Deal Breakers

[Jesse Phillips]

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.