[article] Language Design Deal Breakers

[Simen Kjaeraas]

On Tue, 28 May 2013 05:35:22 +0200, deadalnix <deadalnix at gmail.com> wrote:

> On Monday, 27 May 2013 at 21:55:00 UTC, Simen Kjaeraas wrote:
>> 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?
>
> Same problem exists with any type with @disable this.

Indeed. But not with @disable this() itself. If you don't like the way
it's implemented - roll your own, it's in the library.


>> 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 */ })?
>>
>
> if reference are non nullables, this example don't make any sense.

So you're arguing that all nullables should be banned? How else can you
be so sure my foo can't be 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.
>
> It is. Having everybody considering it isn't is probably why you'll find  
> so much holes in NonNullable.

It isn't. See above.

-- 
Simen