[article] Language Design Deal Breakers

[deadalnix]

On Wednesday, 29 May 2013 at 12:19:54 UTC, Regan Heath wrote:
>> I started discussing this because people where claiming that 
>> non null makes the compiler more complex to implement, which 
>> is completely false.
>
> That's not the argument being made by Simen.  The argument is 
> that @disable this() is a feature which allows a set of 
> features which include but is not limited to not-null, and is 
> therefore a superior feature to have.
>
> Do you agree?
>

I do agree that @disable this is useful. *BUT* the argument made 
is based on the untold assumption that both are mutually 
exclusive, which is not true.

> IMO, this then renders any specific not-null language feature 
> unnecessary.  And, allows a library type to do the job.
>

Most people agree that you'll find 2 useful behavior : non 
nullable and nullable with obligation of handling the null case. 
The default behavior right now provide none of thoses. It behave 
just as if it were non nullable, and simply crash when they 
happen to be null.

This behavior isn't useful. You'll find no argument except 
historical reason (which is a very valid argument BTW) to keep 
that. Everything else is backward rationalization.

> Assuming, as you say, that @disable this() and not-null require 
> the same compiler work, these holes that need plugging would 
> need plugging in either case, right?
>

Yes.