[article] Language Design Deal Breakers

Regan Heath regan at netmail.co.nz
Wed May 29 06:36:16 PDT 2013


On Wed, 29 May 2013 14:15:07 +0100, deadalnix <deadalnix at gmail.com> wrote:

> 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.

I don't believe anyone is arguing that they are mutually exclusive, only  
that @disable is sufficient to do the job.

>> 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.

Which default behaviour?  D's references/pointers?  Or the proposed  
NotNull!(T) library solution?

> 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.

If @disable is insufficient for a NotNull!(T) which does what we need it  
to do, then more features are required.  Ignoring the bugs in @disable, do  
you believe it is insufficient?  If so, can you give us some example  
usages it does not yet support/allow/provide for.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/


More information about the Digitalmars-d mailing list