Null pointer dereferencing in D

[monarch_dodra via Digitalmars-d]

On Saturday, 14 June 2014 at 15:22:07 UTC, Andrei Alexandrescu 
wrote:
> On 6/14/14, 5:33 AM, Dicebot wrote:
>> On Saturday, 14 June 2014 at 10:15:49 UTC, Marc Schütz wrote:
>>> 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()`).
>>
>> Which is effectively a type system hole with @disable this :
>>
>> struct A { @disable this(); }
>> auto a = A.init;
>
> I disagree it's a loophole. A.init is a preexisting object. 
> That said, I do understand that sometimes one wants to inhibit 
> A.init, which can be achieved by e.g. making it a private 
> member. -- Andrei

By that rational, so is "void". If you want default initial 
state, you just use "A()".

Using "A.init" is just the same as using "void": It's "fuck you 
compiler I'm know what I'm doing."

I strongly oppose any notion of being able to customize ".init" 
value or access: It should be a built in and well defined 
concept. If we do allow things like that, than *any* low level 
function, such as emplace, move, swap, destroy or even __ctor 
will exibit unspecified behavior.

".init" should simply mean "the default bit state of the object". 
Let's not make it into anything more complicated than that.