[article] Language Design Deal Breakers

[Regan Heath]

Another outside POV..

On Wed, 29 May 2013 10:20:39 +0100, deadalnix <deadalnix at gmail.com> wrote:
> On Wednesday, 29 May 2013 at 07:50:39 UTC, Kenji Hara wrote:
>> Currently I recognize that it is necessary to fix compiler bugs around
>> @disable this(); at least.
>>
>> @deadalnix, it seems to me that you argue that @disable this(); is
>> insufficient or useless to implement NotNull!T. If so, what is  
>> necessary to
>> do it? What is impossible thing by NotNullT?
>>
>
> No I'm nto saying that this is impossible, I'm saying that @disable  
> this() and non nullable pointer are the exact same feature.
>
> To implement both, the compiler have to track initialization of the  
> value and yell at you if it isn't done, or if the value read before  
> being initialized.
>
> I don't understand why this is so hard to understand.

It's not.  Everyone understands this point, it's not the point of  
contention.

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

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

> Now, as D assume all over the place that everything can be initialized  
> by default, so making @disable this work require a larger design change  
> than simply pluging holes. It means that as of now, some entities can't  
> be initialized by default.

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?

R

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