[article] Language Design Deal Breakers

[deadalnix]

On Monday, 27 May 2013 at 09:08:16 UTC, Walter Bright wrote:
> On 5/27/2013 2:05 AM, deadalnix wrote:
>> On Monday, 27 May 2013 at 08:06:48 UTC, Jonathan M Davis wrote:
>>>> That is not enough. NotNull must be initialized, so the 
>>>> compiler
>>>> have to track initialization in way it don't do today. This 
>>>> is
>>>> the exact same processing required to ensure non null 
>>>> references.
>>>
>>> @disable this(); would solve that.
>>>
>>
>> That is the point, the logic required to support @disable this 
>> is the exact same
>> that the one required to support non null. That is the 
>> freaking same thing :
>> track initialization and yell at the programmer when you can't 
>> find it.
>
> Are you arguing that notnull should be a core language feature 
> instead of a library one?

I'm saying that NonNull require language support, either by 
making it a first class entity, or by introducing some other 
language feature like @disable this(). At the end it doesn't 
change anything for the compiler, the exact same work have to be 
done, simply on different entities. It can't be a 100% library 
feature as the work around @disable this shows.

I think that ideally, nonnull pointer should be a core feature. 
Considering history, a library solution is preferable.

But the argument about compiler feature don't stand, as nonnull 
pointer and @disable this require the exact same processing in 
the compiler.