[article] Language Design Deal Breakers

[Regan Heath]

On Wed, 29 May 2013 15:09:11 +0100, deadalnix <deadalnix at gmail.com> wrote:
> On Wednesday, 29 May 2013 at 13:36:16 UTC, Regan Heath wrote:
>>> 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?
>>
>
> The default behavior. The one you get our of the box. So not NonNullable.

Clearly then NonNullable or @disable is buggy.  Isn't this what Walter  
meant when he said he was going to patch the holes?

So, assuming the implementation of @disable and NotNullable are fixed to  
provide the 2 useful behaviours mentioned above, problem solved right?

>>> 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.
>>
>
> I don't know what you answer to, but clearly not what you are quoting.

I quoted it, but inserted my comment above between your 2 paras.  You then  
stripped it from your reply :P
I have re-quoted it above "Most people agree..".

R

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