[article] Language Design Deal Breakers

[Regan Heath]

On Wed, 29 May 2013 17:27:41 +0100, deadalnix <deadalnix at gmail.com> wrote:

> On Wednesday, 29 May 2013 at 15:02:53 UTC, Regan Heath wrote:
>> Which is what exactly?  That 2 features not-null and @disable this()  
>> are the same thing?  They're not, one is a subset of the other.  That  
>> they require the same compiler functionality, we all agree, but that's  
>> not really important or relevant.  What is relevant is whether NotNull  
>> can be implemented using @disable this, and you've agreed that it can.
>>
>
> In the first place, I was simply answering people that were claiming  
> that non null pointer require more work compiler wise than @disable  
> this(). For some reasons, this was repeated and put out of context.

Ok.  I think the confusion around this statement is that it can be  
interpreted to mean, from the current state of the compiler with @disable  
this() adding not-null requires no more work.  Whereas, you simply meant  
that from a clean slate both features require the same work.  The issue  
here is that your point is irrelevant, because we're not starting from a  
clean slate.

I also don't think the statement is true (see below).

> The point is made to debunk the false argument that non null is extra  
> work. Nothing more, nothing less.

 From the current state of D/DMD not-null /is/ extra work, as Jesse posted:

* 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!

 From a clean slate not-null and @disable this() both require items #1 and  
#2 above, but @disable this() doesn't require item #3.

So either way not-null still requires extra work.

R

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