[article] Language Design Deal Breakers

[deadalnix]

On Tuesday, 28 May 2013 at 13:17:37 UTC, Simen Kjaeraas wrote:
> 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.
>

@disable this isn't a feature you can implement as a lib. You 
can't roll out your own.

>> It is. Having everybody considering it isn't is probably why 
>> you'll find so much holes in NonNullable.
>
> It isn't. See above.

It is; see above :D

More generally, @disable this imply that you have to explicitly 
init something. Just as non nullable. This is the exact same 
problem to solve.