Null pointer dereferencing in D

[Maxim Fomin via Digitalmars-d]

On Saturday, 14 June 2014 at 14:51:10 UTC, Dicebot wrote:
> On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote:
>>> Which is effectively a type system hole with @disable this :
>>>
>>> struct A { @disable this(); }
>>> auto a = A.init;
>>
>> Why this is a type hole if initializer is explicitly provided?
>>
>> The idea of disabled this() is to prevent default 
>> initialization,
>> not to reject potentially buggy one.
>
> Well consider imaginary NotNullable struct that uses "@disable 
> this()" to guarantee that instance of that struct always has 
> meaningful state. By using (NotNullable!T).init you can get 
> value of that type which is in fact null and pass it as an 
> argument to function that expects NotNullable to always be non 
> null. With no casts involved you have just circumvented 
> guarantees static type system was suppose to give.

You can complain if language itself produces code which accesses 
init property. This would be violation of disable premise. 
However, it is clearly you who intentionally asked init property, 
so there is no language fault here.

For example, some time ago implicit disable struct creation 
issues (in context of array copy, out parameter, etc. ) were 
filed and fixed. If you face situation when compiler generates 
default disabled struct without user permission, this would be a 
bug.

The case which you described is a not a type safety problem. 
There is no reinterpretation of object of one type as another 
type (or reading/writing memory which should not have been 
read/written). It is perfectly safe to assign object of type A to 
the same type. What is presented is some sort of design pattern 
violated by the user, not the language (and the goal of the 
pattern cannot be fully achieved in D language).