Null pointer dereferencing in D

[via Digitalmars-d]

On Saturday, 14 June 2014 at 00:40:06 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
> On Sat, 14 Jun 2014 00:34:51 +0200
> Timon Gehr via Digitalmars-d <digitalmars-d at puremagic.com> 
> wrote:
>
>> On 06/13/2014 11:45 PM, Jonathan M Davis via Digitalmars-d 
>> wrote:
>> > On Fri, 13 Jun 2014 21:23:00 +0000
>> > deadalnix via Digitalmars-d <digitalmars-d at puremagic.com> 
>> > wrote:
>> >
>> >> The approach consisting in having non nullable 
>> >> pointers/reference
>> >> by default is the one that is gaining traction and for good
>> >> reasons.
>> >
>> > That interacts _really_ badly with D's approach of requiring 
>> > init values
>> > for all types. We have enough problems with @disable this() 
>> > as it is.
>> >
>> > - Jonathan M Davis
>> >
>>
>> @disable this() and nested structs etc. Trying to require init 
>> values
>> for everything isn't an extraordinarily good idea. It roughly 
>> extends
>> 'nullable by default' to all _structs_ with non-trivial 
>> invariants.
>
> True, some types become problematic when you have to have an 
> init value (like
> a NonNullable struct to make nullable pointers non-nullable), 
> but generic code
> is way more of a pain to write when you can't rely on an init 
> value existing,
> and there are a number of places that the language requires an 
> init value
> (like arrays), making types which don't have init values 
> problematic to use.
> Overall, I think that adding @disable this() to the language 
> was a mistake.

Huh? Types with `@disable this()` still have an `init` value. All 
it does is disallow instantiating the type without specifying an 
initializer (e.g. a struct literal, a value returned from a 
factory function, or `static opCall()`).