[article] Language Design Deal Breakers

[Simen Kjaeraas]

On Mon, 27 May 2013 20:00:30 +0200, deadalnix <deadalnix at gmail.com> wrote:

> On Monday, 27 May 2013 at 17:41:37 UTC, Walter Bright wrote:
>> On 5/27/2013 2:17 AM, deadalnix wrote:
>>> But the argument about compiler feature don't stand, as nonnull  
>>> pointer and
>>> @disable this require the exact same processing in the compiler.
>>
>> Yes, it does stand, as there is a lot of other types that can benefit  
>> from @disable this. If notnull is a core feature, then only that works.
>
> I never said that they are mutually exclusive. All the contrary, I say  
> they are the same thing. And that if you have one, you have no reason  
> not the have the other.

Ah, like that. Your posts could be read as 'non-nullable pointers give
the *exact* same benefits as does @disable this()', which is simply untrue.

Now, if we wanted to add compiler support for non-nullable references, many
more things would need to be decided - how do they look? Do they assert
non-nullness upon initialization/assignment, or are external checks  
required?
Does new Foo() return a non-nullable reference? Must we also add scoped
non-nullness guarantees (if(foo != null) { /* foo is now implicitly
convertible to non-nullable */ })?

So, no. The stuff required to add @disable this() to the language is not  
the
same that is required for non-nullable references. It's certainly an  
important
part of it, but there's still more left, and it's going to make the  
language
harder to implement. Adding a feature that lets non-nullable references be
added in a library is much better.

-- 
Simen